Seed Splitting and Firmware Extension for Secure Cryptocurrency Key Backup, Restore, and Transaction Signing Platform Apparatuses, Methods and Systems

ABSTRACT

The Seed Splitting and Firmware Extension for Secure Cryptocurrency Key Backup, Restore, and Transaction Signing Platform Apparatuses, Methods and Systems (“SFTSP”) transforms transaction signing request, key backup request, key recovery request inputs via SFTSP components into transaction signing response, key backup response, key recovery response outputs. An offline transaction signing request message for a transaction is received by a first cold HSM and includes an encrypted second master key share from a second cold HSM and an encrypted third master key share from a hot HSM. A first master key share is retrieved. The encrypted master key shares are decrypted and, along with the first master key share, used to recover a master private key. A keychain path is determined. A signing private key for the keychain path is generated using the master private key. The transaction is signed using the signing private key, and the generated signature is returned.

This application for letters patent disclosure document describesinventive aspects that include various novel innovations (hereinafter“disclosure”) and contains material that is subject to copyright, maskwork, and/or other intellectual property protection. The respectiveowners of such intellectual property have no objection to the facsimilereproduction of the disclosure by anyone as it appears in publishedPatent Office file/records, but otherwise reserve all rights.

PRIORITY CLAIM

Applicant hereby claims benefit to priority under 35 USC § 120 as acontinuation-in-part of: U.S. patent application Ser. No. 15/984,280,filed May 18, 2018, entitled “Seed Splitting and Firmware Extension forSecure Cryptocurrency Key Backup, Restore, and Transaction SigningPlatform Apparatuses, Methods and Systems”, (attorney docket no. Fideli0506CP1); and which in turn:

-   -   claims benefit to priority under 35 USC § 119 as a        non-provisional conversion of: U.S. provisional patent        application Ser. No. 62/509,011, filed May 19, 2017, entitled        “Secure Firmware Transaction Signing Platform Apparatuses,        Methods and Systems”, (attorney docket no. Fideli 0506PV);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/898,224, filed Feb. 15, 2018, entitled “Firmware Extension        for Secure Cryptocurrency Key Backup, Restore, and Transaction        Signing Platform Apparatuses, Methods and Systems”, (attorney        docket no. FIDELITY0512CP1); and which in turn:    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/456,461 filed Mar. 10, 2017, entitled “Secure Firmware        Transaction Signing Platform Apparatuses, Methods and Systems,”        (attorney docket no. FIDELITY0473US1A);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/210,813, filed Jul. 14, 2016, entitled “Crypto Key Recovery        and Social Aggregating, Fractionally Efficient Transfer        Guidance, Conditional Triggered Transaction, Datastructures,        Apparatuses, Methods and Systems,” (attorney docket no.        Fidelity367US); and which in turn claims benefit to priority        under 35 USC § 119 as a non-provisional conversion of: U.S.        provisional patent application Ser. No. 62/273,447, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity367PV), U.S. provisional patent application        Ser. No. 62/273,449, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity390PV), U.S.        provisional patent application Ser. No. 62/273,450, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity391PV), U.S. provisional patent application        Ser. No. 62/273,452, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity392PV), U.S.        provisional patent application Ser. No. 62/273,453, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fideli 393PV);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/210,817, filed Jul. 14, 2016, entitled “Crypto Voting and        Social Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity390US); and        which in turn claims benefit to priority under 35 USC § 119 as a        non-provisional conversion of: U.S. provisional patent        application Ser. No. 62/273,447, filed Dec. 31, 2015, entitled        “Social Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity367PV), U.S.        provisional patent application Ser. No. 62/273,449, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity390PV), U.S. provisional patent application        Ser. No. 62/273,450, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity391PV), U.S.        provisional patent application Ser. No. 62/273,452, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity392PV), U.S. provisional patent application        Ser. No. 62/273,453, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity393PV);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/210,807, filed Jul. 14, 2016, entitled “Smart Rules and        Social Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity391US); and        which in turn claims benefit to priority under 35 USC § 119 as a        non-provisional conversion of: U.S. provisional patent        application Ser. No. 62/273,447, filed Dec. 31, 2015, entitled        “Social Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity367PV), U.S.        provisional patent application Ser. No. 62/273,449, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity390PV), U.S. provisional patent application        Ser. No. 62/273,450, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity391PV), U.S.        provisional patent application Ser. No. 62/273,452, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity392PV), U.S. provisional patent application        Ser. No. 62/273,453, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity393PV);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/210,795, filed Jul. 14, 2016, entitled “Social Aggregating,        Fractionally Efficient Transfer Guidance, Conditional Triggered        Transaction, Datastructures, Apparatuses, Methods and Systems,”        (attorney docket no. Fidelity392US); and which in turn claims        benefit to priority under 35 USC § 119 as a non-provisional        conversion of: U.S. provisional patent application Ser. No.        62/273,447, filed Dec. 31, 2015, entitled “Social Aggregating,        Fractionally Efficient Transfer Guidance, Conditional Triggered        Transaction, Datastructures, Apparatuses, Methods and Systems,”        (attorney docket no. Fidelity367PV), U.S. provisional patent        application Ser. No. 62/273,449, filed Dec. 31, 2015, entitled        “Social Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity390PV), U.S.        provisional patent application Ser. No. 62/273,450, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity391PV), U.S. provisional patent application        Ser. No. 62/273,452, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity392PV), U.S.        provisional patent application Ser. No. 62/273,453, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fideli 393PV);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/210,821, filed Jul. 14, 2016, entitled “Crypto Captcha and        Social Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity393US); and        which in turn claims benefit to priority under 35 USC § 119 as a        non-provisional conversion of: U.S. provisional patent        application Ser. No. 62/273,447, filed Dec. 31, 2015, entitled        “Social Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity367PV), U.S.        provisional patent application Ser. No. 62/273,449, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity390PV), U.S. provisional patent application        Ser. No. 62/273,450, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fidelity391PV), U.S.        provisional patent application Ser. No. 62/273,452, filed Dec.        31, 2015, entitled “Social Aggregating, Fractionally Efficient        Transfer Guidance, Conditional Triggered Transaction,        Datastructures, Apparatuses, Methods and Systems,” (attorney        docket no. Fidelity392PV), U.S. provisional patent application        Ser. No. 62/273,453, filed Dec. 31, 2015, entitled “Social        Aggregating, Fractionally Efficient Transfer Guidance,        Conditional Triggered Transaction, Datastructures, Apparatuses,        Methods and Systems,” (attorney docket no. Fideli 393PV);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        14/799,282, filed Jul. 14, 2015, entitled “Point-to-Point        Transaction Guidance Apparatuses, Methods and Systems,”        (attorney docket no. Fideli 336US1);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        14/799,242, filed Jul. 14, 2015, entitled “Point-to-Point        Transaction Guidance Apparatuses, Methods and Systems,”        (attorney docket no. Fideli 336US2);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        14/799,229, filed Jul. 14, 2015, entitled “Point-to-Point        Transaction Guidance Apparatuses, Methods and Systems,”        (attorney docket no. Fideli 336US3);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        14/963,165, filed Dec. 8, 2015, entitled “Social Aggregated        Fractional Equity Transaction Partitioned Acquisition        Apparatuses, Methods and Systems,” (attorney docket no. Fideli        339US);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/019,926, filed Feb. 9, 2016, entitled “Computationally        Efficient Transfer Processing and Auditing Apparatuses, Methods        and Systems,” (attorney docket no. Fideli 340US);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/209,701, filed Jul. 13, 2016, entitled “Point-to-Point        Transaction Guidance Apparatuses, Methods and Systems,”        (attorney docket no. Fideli 0336CP1);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/209,709, filed Jul. 13, 2016, entitled “Point-to-Point        Transaction Guidance Apparatuses, Methods and Systems,”        (attorney docket no. Fideli 0336CP2);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/209,714, filed Jul. 13, 2016, entitled “Point-to-Point        Transaction Guidance Apparatuses, Methods and Systems,”        (attorney docket no. Fideli 0336CP3);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: Patent Cooperation Treaty application        serial no. PCT/US16/42169, filed Jul. 13, 2016, entitled        “Computationally Efficient Transfer Processing, Auditing, and        Search Apparatuses, Methods and Systems,” (attorney docket no.        Fideli 0340PC);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/210,781, filed Jul. 14, 2016, entitled “Computationally        Efficient Transfer Processing, Auditing, and Search Apparatuses,        Methods and Systems,” (attorney docket no. Fideli 0340CP1);    -   claims benefit to priority under 35 USC § 120 as a        continuation-in-part of: U.S. patent application Ser. No.        15/486,243, filed Apr. 12, 2017, entitled “Computationally        Efficient Transfer Processing, Auditing, and Search Apparatuses,        Methods and Systems,” (attorney docket no. Fideli 0340CP2A).

The entire contents of the aforementioned applications are hereinexpressly incorporated by reference.

FIELD

The present innovations generally address information technology, andmore particularly, include Seed Splitting and Firmware Extension forSecure Cryptocurrency Key Backup, Restore, and Transaction SigningPlatform Apparatuses, Methods and Systems.

However, in order to develop a reader's understanding of theinnovations, disclosures have been compiled into a single description toillustrate and clarify how aspects of these innovations operateindependently, interoperate as between individual innovations, and/orcooperate collectively. The application goes on to further describe theinterrelations and synergies as between the various innovations; all ofwhich is to further compliance with 35 U.S.C. § 112.

BACKGROUND

Bitcoin is an open source software application and a shared protocol. Itallows users to anonymously and instantaneously transact Bitcoin, adigital currency, without needing to trust counterparties or separateintermediaries. Bitcoin achieves this trustless anonymous network usingpublic/private key pairs, a popular encryption technique.

BRIEF DESCRIPTION OF THE DRAWINGS

Appendices and/or drawings illustrating various, non-limiting, example,innovative aspects of the Seed Splitting and Firmware Extension forSecure Cryptocurrency Key Backup, Restore, and Transaction SigningPlatform Apparatuses, Methods and Systems (hereinafter “SFTSP”)disclosure, include:

FIGS. 1A-B show exemplary architectures for the SFTSP;

FIGS. 2A-B show exemplary deployment diagrams for the SFTSP;

FIG. 3 shows an exemplary single HSM use case for the SFTSP;

FIGS. 4A-B show exemplary dual HSM use cases for the SFTSP;

FIG. 5A shows a datagraph diagram illustrating embodiments of a dataflow for the SFTSP;

FIGS. 5B-C show a datagraph diagram illustrating embodiments of a dataflow for the SFTSP;

FIG. 6A shows a logic flow diagram illustrating embodiments of a securefirmware transaction signing (SFTS) component for the SFTSP;

FIG. 6B shows a logic flow diagram illustrating embodiments of atransaction server transaction signing (TSTS) component for the SFTSP;

FIG. 6C shows a logic flow diagram illustrating embodiments of a securefirmware transaction signing (SFTS) component for the SFTSP;

FIG. 7 shows an exemplary data model for the SFTSP;

FIG. 8 shows an exemplary authentication model for the SFTSP;

FIG. 9 shows an exemplary authentication use case for the SFTSP;

FIG. 10 shows an exemplary key backup model for the SFTSP;

FIGS. 11A-B show a datagraph diagram illustrating embodiments of a dataflow for the SFTSP;

FIG. 12 shows a logic flow diagram illustrating embodiments of a backuputility key backup (BUKB) component for the SFTSP;

FIG. 13 shows a logic flow diagram illustrating embodiments of a securefirmware key backup (SFKB) component for the SFTSP;

FIG. 14 shows a screenshot diagram illustrating embodiments of theSFTSP;

FIG. 15 shows a screenshot diagram illustrating embodiments of theSFTSP;

FIG. 16A shows an exemplary seed shares geographic distribution modelfor the SFTSP;

FIG. 16B shows an exemplary seed shares implementation case for theSFTSP;

FIG. 17 shows a screenshot diagram illustrating embodiments of theSFTSP;

FIG. 18 shows an exemplary key recovery model for the SFTSP;

FIG. 19 shows a datagraph diagram illustrating embodiments of a dataflow for the SFTSP;

FIG. 20 shows a logic flow diagram illustrating embodiments of arecovery utility key recovery (RUKR) component for the SFTSP;

FIG. 21 shows a logic flow diagram illustrating embodiments of a securefirmware key recovery (SFKR) component for the SFTSP;

FIG. 22 shows a screenshot diagram illustrating embodiments of theSFTSP;

FIG. 23 shows an exemplary architecture for the SFTSP;

FIGS. 24A-B show a datagraph diagram illustrating embodiments of a dataflow for the SFTSP;

FIG. 25 shows a logic flow diagram illustrating embodiments of atransaction server transaction signing (TSTS) component for the SFTSP;

FIG. 26 shows a logic flow diagram illustrating embodiments of a securefirmware transaction signing (SFTS) component for the SFTSP;

FIGS. 27A-C show a datagraph diagram illustrating embodiments of a dataflow for the SFTSP;

FIG. 28 shows a logic flow diagram illustrating embodiments of an onlinetransaction server transaction signing (NTSTS) component for the SFTSP;

FIG. 29 shows a logic flow diagram illustrating embodiments of a hotsecure firmware transaction signing (HSFTS) component for the SFTSP;

FIG. 30 shows a logic flow diagram illustrating embodiments of anoffline transaction server transaction signing (FTSTS) component for theSFTSP;

FIG. 31 shows a logic flow diagram illustrating embodiments of a coldsecure firmware transaction signing (CSFTS) component for the SFTSP;

FIG. 32 shows a block diagram illustrating embodiments of a SFTSPcontroller.

Generally, the leading number of each citation number within thedrawings indicates the figure in which that citation number isintroduced and/or detailed. As such, a detailed discussion of citationnumber 101 would be found and/or introduced in FIG. 1. Citation number201 is introduced in FIG. 2, etc. Any citation and/or reference numbersare not necessarily sequences but rather just example orders that may berearranged and other orders are contemplated.

DETAILED DESCRIPTION

The Seed Splitting and Firmware Extension for Secure Cryptocurrency KeyBackup, Restore, and Transaction Signing Platform Apparatuses, Methodsand Systems (hereinafter “SFTSP”) transforms transaction signingrequest, key backup request, key recovery request inputs, via SFTSPcomponents (e.g., SFTS, BUKB, SFKB, RUKR, SFKR, TSTS, NTSTS, HSFTS,FTSTS, CSFTS, etc. components), into transaction signing response, keybackup response, key recovery response outputs. The SFTSP components, invarious embodiments, implement advantageous features as set forth below.

Introduction

Cryptocurrency (e.g., Bitcoin, Ethereum) funds and appropriateoperations on them are intrinsically linked to asymmetric cryptographykeys: funds are received at addresses based on public keys and spentusing private keys that confirm ownership. Non-trivial Bitcoin walletimplementations operate multiple keys for the following reasons:

a) Operations are published on the Blockchain and become publiclyvisible

b) Reuse of receiving addresses allows data analysis that leads toidentification of actively used addresses with significant funds andcompromises the privacy of cryptocurrency transactions

c) An enterprise-hosted wallet structure usually utilizes differentaccounts for different organizational units and for different purposes

The use of independent keys for each operation, purpose, ororganizational unit, aka flat wallets, makes both backing up keys andsecuring keys very complicated. In order to address this issue, Bitcoinimprovement proposal #32 (Bip32) describes a deterministic algorithmthat allows the building of a tree of private/public key pairs from asingle secret seed (e.g., master key) and allows creation and managementof hierarchical deterministic wallets instead of flat ones. Accordingly,by following Bip32:

a) Mapping of addresses for organizational units, particular operations,or purposes to transaction signing keys is done in a predictable manner

b) Securing of persistent keys is reduced to securing the seed

c) Backup and recovery procedures are simplified because the wholehierarchy of keys can be restored from the seed

A reliable way (e.g., one of the most secure ways) to store information(e.g., crypto keys) securely is inside a FIPS 140-2—certified hardwaresecurity module (HSM) appliance that provides tamper-proof storage ofsensitive information. There is no external access to the dynamic memoryinside a HSM, and, in some implementations, any attempts to physicallyaccess the tamper-proof storage may trigger complete deletion of storedinformation.

Current industry implementations of wallet and key management systemsfor secure wallets utilize a (e.g., software-based) Transaction SigningServer (TSS) to implement key derivation and transaction signingprocedures. This creates a security threat because private keys,including the master key, are created in TSS memory, where, as thememory of a TSS server does not have strict physical boundaries, theycan be stolen by an attacker. Multiple known memory attacks, such asDirect Memory Access (e.g., steal sensitive information directly fromthe memory) and Core Dump (e.g., cause a system crash and stealinformation from the memory dump generated during the crash) exist, and,despite existing protective measures and practices, the risk of privatekeys being stolen from the TSS memory (e.g., by malicious insiders)remains high. Additionally, as there is no reliable way to identify suchunauthorized memory access and key theft, keys may be stolen and used ata later time when fund losses associated with those keys aresignificant.

Further, as cryptographic funds are tightly coupled with cryptographickeys, the loss or theft of keys is identical to the loss of funds. Incase of hierarchical deterministic wallets, loss or theft of seeds isidentical to the loss or theft of funds associated with keys that can bederived from these seeds. This means that seeds should be backed upreliably and securely. Even though multiple backup copies of HSM devicesstoring seeds may be created, it is desirable to have distributed hardcopies of keys (e.g., paper printouts, metal engravings), which providemeans to recover keys in case of severe disasters when not only HSMdevices but whole data centers may become unavailable. Regularhardcopies of seeds suffer from the following weaknesses:

a) If stolen, they provide full seeds to an attacker

b) In order to be printed, seeds are extracted from HSMs into acomputer's memory in the plain text format and can be stolen usingmemory targeting attacks

c) While being recovered from hard copies, seeds are processed in acomputer's memory in the plain text format and can be stolen usingmemory targeting attacks

d) While being distributed from one location to another or recoveredfrom hard copies, seeds can be copied and even memorized by theoperational staff

Thus, even though seeds or private keys may not be exposed outside ofHSM during regular cryptographic operations, during key generation, keybackup and restore operations, since master seeds have to exist outsideof HSM for a period of time before being deposited into bank safety boxfor safe backup store, there exist attack vectors and seed materials canbe compromised.

In one additional embodiment, the SFTSP includes DeterministicDerivation of Cryptocurrency Signing Keys with Split Master Seed andEnforcement of M-of-N Authentication Policy. This supports the SFTSPwith innovations in Bitcoin, Ethereum and Blockchain, new service andproduct offerings in cryptocurrency. It includes splitting Bitcoin orEthereum master private key into multiple key shares (e.g., into twohalves) when stored in FIPS 140-2 Level 3 HSM appliances to achievecombined BIP-32 hierarchical deterministic key derivation fortransaction signing and M-of-N authentication enforcement on HSMs. Inone implementation, two paired HSMs may be utilized such that a firstHSM storing a first master key share receives an encrypted second masterkey share from a second HSM whose access is controlled by M-of-Nauthentication policy, and the first HSM decrypts the second master keyshare and recovers the master private key from the two master keyshares. This technique is applied to a Bitcoin cold storage key vaultand fund transfer implementation to protect master private keys fromphysical and/or software key theft and to enforce MofN (e.g., 2-personrule) security policy with regard to accessing the transaction signingcapability on HSM.

In one additional embodiment, the SFTSP may be utilized to providemulti-signature support for Externally Owned Account (EOA) transactionson Ethereum blockchain. Previously, to support more secure multiplesignatures as in Bitcoin, Ethereum smart-contracts have been used. Anysmart contract multi-sig implementation carries inherent risk of fundloss and is known to be subject to various attacks, because potentialcode bugs and vulnerabilities could be introduced in contract Soliditycode. Two well-known examples of these types of attacks are ParityWallet Multi-sig hack and DAO hack. The SFTSP achieves the same securestore with multiple keys in a multi-sig wallet but does so withouthaving the risk of a smart contract to secure Ethereum transactions.

SFTSP

FIG. 1A shows an exemplary architecture for the SFTSP. In FIG. 1A, a TSSutilizes a custom transaction signing API via a HSM Access Provider(e.g., a module used to communicate with a HSM) to request transactionsigning by a HSM (e.g., Gemalto's SafeNet HSM). The HSM may receive suchrequests via a message processing module of the HSM's firmware, andrespond with signed transactions.

The HSM's firmware module is extended to include a secure firmwaretransaction signing (SFTS) module, which includes a SFTS componentand/or other components (e.g., SFKB, SFKR, HSFTS, CSFTS) and animplementation of Bip32 algorithms In some implementations, the SFTSmodule may utilize PKCS#11 API (e.g., via a Cryptoki Library) formessage signing and hash generation. In some implementations, the SFTSmodule may implement high precision mathematical operations either adhoc or using open source libraries (e.g., OpenSSL). In one embodiment,utilizing an HSM extended with a SFTS module to implement key derivationand transaction signing procedures improves security of hierarchicaldeterministic wallets.

FIG. 1B shows an exemplary architecture for the SFTSP. As shown in FIG.1B, two master private key (or seed) shares of a master private key(e.g., a 64-byte seed) were generated (e.g., via Shamir's SecretSharing) and stored on HSMs. Seed share one (e.g., a 64-byte seed share)was generated and/or stored (e.g., with proper attributes) on Gemalto'sProtectServer PCI-e HSM. Seed share two (e.g., a 64-byte seed share) wasgenerated and/or stored (e.g., with proper attributes) on Gemalto's G5USB HSM. In one implementation, the following PKCS#11 key objectattributes may be set:

CKA_EXTRACTABLE=whether a seed share is extractable from and can bewrapped out of HSM

CKA_TOKEN=whether a seed share is a permanent or a transient/sessionobject on HSM

CKA_SENSITIVE=whether a seed share is readable (e.g., can be revealed inplaintext) outside of HSM

For example, attributes for seed share one may be set to make seed shareone sensitive and not exportable. In another example, attributes forseed share two may be set to make seed share two sensitive butexportable.

In one implementation, each seed share may be backed up (e.g., using akey backup model described with regard to FIG. 10) and may be recoveredindependently of other seed shares.

At 100, in order to sign a transaction (e.g., to execute a fund transferCLI program to transfer funds from a cold wallet to a hot wallet),multiple (e.g., three) operators may have to be present (e.g.,physically present) to authenticate to a TSS and/or the HSMs. Forexample, a system administrator (e.g., SysAdmin) may have to provide aTSS login password, and/or PCI-e HSM slot pin, and/or USB HSM partitionpassword. In another example, two operators (e.g., Operator₁ andOperator₂) may have to be authenticated to the USB HSM (e.g., via2-factor authentication process with the first factor being a physicalsecurity token and the second factor being a PIN) via an authenticationentry device (e.g., a PED) to enforce MofN security policy for exportingseed share two, and/or to the PCI-e HSM (e.g., via a PIN), and/or to theTSS (e.g., via a password).

At 101, an RSA key pair (e.g., a RSA public key RSApub, and a RSAprivate key RSApriv) may be generated on the PCI-e HSM aswrapping/unwrapping keys. At 102, the public key RSApub may be exportedfrom the PCI-e HSM to RAM of the TSS for the fund transfer CLI program.At 103, the fund transfer CLI program may import the public key RSApubinto the USB HSM. At 104, the USB HSM may wrap (e.g., encrypt) seedshare two with the wrapping key RSApub and export the wrapped seed sharetwo to RAM of the TSS for the fund transfer CLI program. At 105, thefund transfer CLI program may import the wrapped seed share two into thePCI-e HSM. At 106, the PCI-e HSM may unwrap (e.g., decrypt) the wrappedseed share two with the unwrapping key RSAPriv back to its original bytematerials. Proper attribute settings for the unwrapped seed share twomay be set. At 107, a method such as Shamir's Secret Sharing may beutilized (e.g., via a SFTS module) to recover the master private key(e.g., from seed share one and seed share two) for BIP-32 hierarchicaldeterministic key derivation (e.g., via the SFTS module). At 108, thetransaction may be signed using the BIP-32 derived private key (e.g.,via the SFTS module).

In one implementation, key materials other than seed share one on PCI-eHSM and seed share two on USB HSM are deleted from memory when a sessionis over (e.g., when the transaction is signed). At 109, RSApub, RSApriv,wrapped seed share two, unwrapped seed share two, the recovered masterprivate key, and the BIP-32 derived private key may be deleted frommemory of PCI-e HSM. At 110, RSApub and wrapped seed share two may bedeleted from memory of USB HSM and/or TSS.

FIG. 2A shows an exemplary deployment diagram for the SFTSP. In FIG. 2A,a deployment diagram for hot and cold storages of funds (e.g., wallets)is shown. A hot wallet (e.g., holding a small amount of funds for onlinepurchases) is using an online network appliance HSM hosting both a hotwallet master private key and a SFTS component. A cold wallet (e.g.,holding the majority of funds offline), is using an offline (e.g.,PCI-e) HSM hosting a SFTS component and a RSA private key used fordecrypting a cold wallet master private key retrieved from a portableHSM. The portable (e.g., USB-connected) HSM hosts the cold wallet masterprivate key and the RSA public key matching the RSA private key storedin the offline (e.g., PCI-e) HSM.

In some embodiments, the SFTSP may protect addresses used for receivingfunds in transactions between paired cold and hot wallets. Theseaddresses are derived from master keys in a similar way as thederivation of private keys used for transaction signing. Accordingly,these addresses may be protected if transaction composition code usesaddresses generated directly from a HSM to transfer funds between coldand hot wallets.

FIG. 2B shows another exemplary deployment diagram for the SFTSP. InFIG. 2B, a deployment diagram for cold storages of funds is shown. Acold wallet (e.g., holding the majority of funds offline), is using anoffline (e.g., PCI-e) HSM hosting a SFTS component, a first cold walletmaster private key share, and a RSA private key used for decrypting asecond cold wallet master private key share retrieved from a portableHSM. The portable (e.g., USB-connected) HSM hosts the second cold walletmaster private key share and the RSA public key matching the RSA privatekey stored in the offline (e.g., PCI-e) HSM. The portable HSM uses anauthentication entry device (e.g., a PED) to enforce MofN securitypolicy for exporting the second cold wallet master private key share.

FIG. 3 shows an exemplary single HSM use case for the SFTSP. Forexample, this use case may be utilized for a hot wallet. In FIG. 3, aclient application 310 (e.g., utilized by a user via a client device)may send a transaction signing request (e.g., including transaction datato sign and a keychain path to be used for Bip32 key derivation) to aTSS 320. The TSS may include an in-memory cache 322 that stores a masterpublic key 324. For example, the TSS may provide the master public keyto the client application, if requested.

The TSS may forward the transaction signing request to a HSM 330. Forexample, the HSM may be a network-attached HSM. The HSM's tamper-proofstorage (e.g., the HSM's firmware) may store a master private key (e.g.,an ECDSA private key) 334 and a SFTS module 336. The HSM may utilize themaster private key and the SFTS module to sign the transaction, and mayrespond with a signed transaction (e.g., ECDSA signature inDistinguished Encoding Rules (DER) format). Sensitive operations, suchas key derivation and transaction signing, are implemented inside theHSM appliance and master secret key materials do not leave thetamper-proof storage. Tamper-proof storage ensures that secretinformation is inaccessible to an attacker and that any attempted attackis detected and reported to the appropriate operational group.

FIG. 4A shows an exemplary dual HSM use case for the SFTSP. For example,this use case may be utilized for a cold wallet (e.g., corresponding tothe cold wallet shown in FIG. 2A). In FIG. 4A, a client application 410(e.g., utilized by a user via a client device) may send a transactionsigning request (e.g., including transaction data to sign and a keychainpath to be used for Bip32 key derivation) to a TSS 420. The TSS mayinclude an in-memory cache 422 that stores a master public key 424. Forexample, the TSS may provide the master public key to the clientapplication, if requested.

The TSS may forward the transaction signing request to a first HSM 430.For example, the first HSM may be a PCIe HSM (e.g., installed in a TSS(e.g., machine)). The first HSM's tamper-proof storage (e.g., the firstHSM's firmware) may store a private key decryption key (e.g., an RSAprivate key) 434 and a SFTS module 436.

The first HSM may send a get master request to a second HSM 440. Forexample, the second HSM may be a portable USB HSM. The second HSM'stamper-proof storage (e.g., the second HSM's firmware) may store amaster private key (e.g., an ECDSA private key) 444 and a public keyencryption key (e.g., an RSA public key that corresponds to the RSAprivate key stored in the first HSM's tamper-proof storage) 446. In oneembodiment, the second HSM may include a split credentials PIN entrydevice (PED) to provide for multiple-person (e.g., M-of-N) user accessrule for HSM activation and/or operation (e.g., 2-of-3 operationenforcement that allows access to the master private key if at least twoout of three people provide their separate credentials to the secondHSM). See FIGS. 8 and 9 for additional details regarding M-of-Nauthentication.

The second HSM may encrypt the master private key using the public keyencryption key (e.g., associated with the first HSM), and may respond tothe get master request by returning the encrypted master private key tothe first HSM. The first HSM may decrypt the master private key usingthe private key decryption key, may utilize the decrypted master privatekey and the SFTS module to sign the transaction, and may respond with asigned transaction (e.g., ECDSA signature in DER format). Sensitiveoperations, such as key derivation and transaction signing, areimplemented inside the first HSM appliance and secret key materials areencrypted when transferred between the two HSMs.

FIG. 4B shows an exemplary dual HSM use case for the SFTSP. For example,this use case may be utilized for a cold wallet (e.g., corresponding tothe cold wallet shown in FIG. 2B). In FIG. 4B, a client application 410(e.g., utilized by a user via a client device) may send a transactionsigning request (e.g., including transaction data to sign and a keychainpath to be used for Bip32 key derivation) to a TSS 420. The TSS mayinclude an in-memory cache 422 that stores a master public key 424. Forexample, the TSS may provide the master public key to the clientapplication, if requested.

The TSS may forward the transaction signing request to a first HSM 430.For example, the first HSM may be a PCIe HSM (e.g., installed in a TSS(e.g., machine)). The first HSM's tamper-proof storage (e.g., the firstHSM's firmware) may store a private key decryption key (e.g., an RSAprivate key) 434, a SFTS module 436, and a first master private keyshare (e.g., an ECDSA private key share) 438.

The first HSM may send a get master request to a second HSM 440. Forexample, the second HSM may be a portable USB HSM. The second HSM'stamper-proof storage (e.g., the second HSM's firmware) may store asecond master private key share (e.g., an ECDSA private key share) 444and a public key encryption key (e.g., an RSA public key thatcorresponds to the RSA private key stored in the first HSM'stamper-proof storage) 446. In one embodiment, the second HSM may includea split credentials PIN entry device (PED) to provide formultiple-person (e.g., M-of-N) user access rule for HSM activationand/or operation (e.g., 2-of-3 operation enforcement that allows accessto the second master private key share if at least two out of threepeople provide their separate credentials to the second HSM). See FIGS.8 and 9 for additional details regarding M-of-N authentication.

The second HSM may encrypt the second master private key share using thepublic key encryption key (e.g., associated with the first HSM), and mayrespond to the get master request by returning the encrypted secondmaster private key share to the first HSM. The first HSM may decrypt thesecond master private key share using the private key decryption key,may utilize the decrypted second master private key share, the firstmaster private key share, any other master private key share(s) (e.g.,in implementations where the master private key is split into more thantwo shares and retrieved from multiple portable HSMs (e.g., toreassemble the master private key from three shares)), and the SFTSmodule to sign the transaction, and may respond with a signedtransaction (e.g., ECDSA signature in DER format). Sensitive operations,such as key derivation and transaction signing, are implemented insidethe first HSM appliance and secret key materials are encrypted whentransferred between the two HSMs.

FIG. 5A shows a datagraph diagram illustrating embodiments of a dataflow for the SFTSP. In FIG. 5A, dashed lines indicate data flow elementsthat may be more likely to be optional. In FIG. 5A, a client 502 maysend a transaction signing (TS) request 521 to a TSS server 506 torequest that a transaction be signed. For example, the client may be adesktop, a laptop, a tablet, a smartphone, and/or the like that isexecuting a client application. In one implementation, the TS requestmay include data such as a request identifier, user authentication data,a request type (e.g., sign message hash, get address hash), a walletidentifier, a transaction identifier, a transaction hash, a keychainpath, and/or the like. In one embodiment, the client may provide thefollowing example TS request, substantially in the form of a (Secure)Hypertext Transfer Protocol (“HTTP(S)”) POST message includingeXtensible Markup Language (“XML”) formatted data, as provided below:

POST /authrequest.php HTTP/1.1 Host: www.server.com Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <auth_request> <timestamp>2020-12-31 23:59:59</timestamp><user_accounts_details> <user_account_credentials><user_name>JohnDaDoeDoeDoooe@gmail.com</account_name><password>abc123</password> //OPTIONAL <cookie>cookieID</cookie>//OPTIONAL <digital_cert_link>www.mydigitalcertificate.com/JohnDoeDaDoeDoe@gmail.com/mycertifcate.dc</digital_cert_link> //OPTIONAL<digital_certificate>_DATA_</digital_certificate></user_account_credentials> </user_accounts_details> <TS_request><request_identifier>ID_request_1</request_identifier><request_type>SIGN_TRANSACTION</request_type><wallet_identifier>ID_Wallet1</wallet_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><transaction_hash>256-bit hash value to be signed</transaction_hash><keychain_path>m/0/0/1/0</keychain_path> </TS_request> </auth_request>

The TSS server may send a TS request message 525 to a HSM 510 to requestthat the HSM sign the transaction. In one implementation, the TS requestmessage may be sent via a HSM Access Provider and may include data suchas a request identifier, a request type (e.g., sign message hash, getaddress hash), a wallet identifier, a transaction hash, a keychain path,and/or the like. For example, the TSS server may provide the followingexample TS request message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /TS_request_message.php HTTP/1.1 Host: www.server.com Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_request_message><request_identifier>ID_request_2</request_identifier><request_type>SIGN_TRANSACTION</request_type><wallet_identifier>ID_Wallet1</wallet_identifier><transaction_hash>256-bit hash value to be signed</transaction_hash><keychain_path>m/0/0/1/0</keychain_path> </TS_request_message>

The HSM may make a SFTS API call 529 to a SFTS module 518 to requestthat the SFTS module sign the transaction. In one implementation, theSFTS API call may include data such as a request type (e.g., signmessage hash, get address hash), a wallet identifier, a transactionhash, a keychain path, and/or the like.

Data provided in the SFTS API call may be used by a secure firmwaretransaction signing (SFTS) component 533 to sign the transaction (e.g.,to generate an ECDSA signature in DER format). See FIG. 6A foradditional details regarding the SFTS component.

In some embodiments, the SFTS module may send a master key requestmessage 537 to a portable HSM 514 to request a master private key (e.g.,for a specified wallet) from the portable HSM. In one implementation,the master key request message may include data such as a requestidentifier, a calling HSM identifier, a wallet identifier, and/or thelike. For example, the SFTS module may provide the following examplemaster key request message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /master_key_request_message.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_request_message><request_identifier>ID_request_3</request_identifier><calling_HSM_identifier>ID_HSM_1</calling_HSM_identifier><wallet_identifier>ID_Wallet1</wallet_identifier></master_key_request_message>

The portable HSM may provide the encrypted master private key to theSFTS module via a master key response message 541.

The SFTS module may send SFTS response data 545 to the HSM in responseto the SFTS API call. In one implementation, the SFTS response data mayinclude an ECDSA signature in DER format.

The HSM may send a TS response message 549 to the TSS server (e.g., viaa HSM Access Provider). In one implementation, the TS response messagemay include data such as a response identifier, a transaction signature,and/or the like. For example, the HSM may provide the following exampleTS response message, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /TS_response_message.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <TS_response_message><response_identifier>ID_response_2</response_identifier><transaction_signature>ECDSA signature in DERformat</transaction_signature> </TS_response_message>

The TSS server may send a TS response 553 to the client. In oneimplementation, the TS response may include data such as a responseidentifier, a transaction identifier, a transaction signature, and/orthe like. For example, the TSS server may provide the following exampleTS response, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /TS_response.php HTTP/1.1 Host: www.server.com Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_response><response_identifier>ID_response_1</response_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><transaction_signature>ECDSA signature in DERformat</transaction_signature> </TS_response>

FIGS. 5B-C show a datagraph diagram illustrating embodiments of a dataflow for the SFTSP. In FIGS. 5B-C, a client 502 may send a transactionsigning (TS) request 521 to a TSS server 506 to request that atransaction be signed. For example, the client may be an air-gappeddesktop, a laptop, a tablet, a smartphone, and/or the like that isexecuting a client application. In one implementation, the TS requestmay include data such as a request identifier, user authentication data,a request type (e.g., sign message hash, get address hash), a walletidentifier, a transaction identifier, a transaction hash, a keychainpath, and/or the like. In one embodiment, the client may provide thefollowing example TS request, substantially in the form of a HTTP(S)POST message including XML-formatted data, as provided below:

POST /authrequest.php HTTP/1.1 Host: localhost Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <auth_request> <timestamp>2020-12-31 23:59:59</timestamp><user_accounts_details> <user_account_credentials><user_name>JohnDaDoeDoeDoooe@gmail.com</account_name><password>abc123</password> //OPTIONAL <cookie>cookieID</cookie>//OPTIONAL <digital_cert_link>www.mydigitalcertificate.com/JohnDoeDaDoeDoe@gmail.com/mycertifcate.dc</digital_cert_link> //OPTIONAL<digital_certificate>_DATA_</digital_certificate></user_account_credentials> </user_accounts_details> <TS_request><request_identifier>ID_request_1</request_identifier><request_type>SIGN_TRANSACTION</request_type><wallet_identifier>ID_Wallet1</wallet_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><transaction_hash>256-bit hash value to be signed</transaction_hash><keychain_path>m/0/0/1/0</keychain_path> </TS_request> </auth_request>

A transaction server transaction signing (TSTS) component 525 mayutilize parameters provided in the TS request to facilitate transactionsigning. See FIG. 6B for additional details regarding the TSTScomponent.

The TSS server may send a public key request message 529 to a HSM 510 torequest a RSA public key from the HSM. In one implementation, the publickey request message may be sent via a HSM Access Provider and mayinclude data such as a request identifier, a transaction identifier,and/or the like. In one embodiment, the TSS server may provide thefollowing example public key request message, substantially in the formof a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /public_key_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <public_key_request_message><request_identifier>ID_request_2</request_identifier><transaction_identifier>ID_transaction_1</transaction_identifier></public_key_request_message>

The HSM may provide a RSA public key to the TSS server via a public keyresponse message 533. In one implementation, the public key responsemessage may include data such as a response identifier, a transactionidentifier, a RSA public key, and/or the like. In one embodiment, theHSM may provide the following example public key response message,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /public_key_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <public_key_response_message><response_identifier>ID_response_2</response_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><RSA_public_key>RSA public key provided by the HSM</RSA_public_key></public_key_response_message>

The TSS server may send a master key share request message 537 to aportable HSM 514 to request an encrypted master key share (e.g., for aspecified wallet) from the portable HSM. In one implementation, themaster key share request message may include data such as a requestidentifier, a transaction identifier, a wallet identifier, a RSA publickey, and/or the like. In one embodiment, the TSS server may provide thefollowing example master key share request message, substantially in theform of a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /master_key_share_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_share_request_message><request_identifier>ID_request_3</request_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><wallet_identifier>ID_Wallet1</wallet_identifier> <RSA_public_key>RSApublic key provided by the HSM</RSA_public_key></master_key_share_request_message>

The portable HSM may provide the encrypted master key share to the TSSserver via a master key share response message 541. In oneimplementation, the master key share response message may include datasuch as a response identifier, a transaction identifier, a walletidentifier, an encrypted master key share, and/or the like. In oneembodiment, the portable HSM may provide the following example masterkey share response message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /master_key_share_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_share_response_message><response_identifier>ID_response_3</response_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><wallet_identifier>ID_Wallet1</wallet_identifier><master_key_share>encrypted master key share provided by the portableHSM</master_key_share> </master_key_share_response_message>

The TSS server may send a TS request message 545 to the HSM to requestthat the HSM sign the transaction. In one implementation, the TS requestmessage may be sent via a HSM Access Provider and may include data suchas a request identifier, a request type (e.g., sign message hash, getaddress hash), a wallet identifier, a transaction identifier, atransaction hash, a keychain path, an encrypted master key share, and/orthe like. For example, the TSS server may provide the following exampleTS request message, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /TS_request_message.php HTTP/1.1 Host: localhost Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_request_message><request_identifier>ID_request_4</request_identifier><request_type>SIGN_TRANSACTION</request_type><wallet_identifier>ID_Wallet1</wallet_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><transaction_hash>256-bit hash value to be signed</transaction_hash><keychain_path>m/0/0/1/0</keychain_path> <master_key_share>encryptedmaster key share provided by the portable HSM</master_key_share></TS_request_message>

The HSM may make a SFTS API call 549 to a SFTS module 518 to requestthat the SFTS module sign the transaction. In one implementation, theSFTS API call may include data such as a request type (e.g., signmessage hash, get address hash), a wallet identifier, a transactionidentifier, a transaction hash, a keychain path, an encrypted master keyshare, and/or the like.

Data provided in the SFTS API call may be used by a secure firmwaretransaction signing (SFTS) component 553 to determine a master privatekey from master key shares and to sign the transaction (e.g., togenerate an ECDSA signature in DER format). See FIG. 6C for additionaldetails regarding the SFTS component.

The SFTS module may send SFTS response data 557 to the HSM in responseto the SFTS API call. In one implementation, the SFTS response data mayinclude an ECDSA signature in DER format.

The HSM may send a TS response message 561 to the TSS server (e.g., viaa HSM Access Provider). In one implementation, the TS response messagemay include data such as a response identifier, a transactionidentifier, a transaction signature, and/or the like. For example, theHSM may provide the following example TS response message, substantiallyin the form of a HTTP(S) POST message including XML-formatted data, asprovided below:

POST /TS_response_message.php HTTP/1.1 Host: localhost Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_response_message><response_identifier>ID_response_4</response_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><transaction_signature>ECDSA signature in DERformat</transaction_signature> </TS_response_message>

The TSS server may send a TS response 565 to the client. In oneimplementation, the TS response may include data such as a responseidentifier, a transaction identifier, a transaction signature, and/orthe like. For example, the TSS server may provide the following exampleTS response, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /TS_response.php HTTP/1.1 Host: www.server.com Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_response><response_identifier>ID_response_1</response_identifier><transaction_identifier>ID_transaction_1</transaction_identifier><transaction_signature>ECDSA signature in DERformat</transaction_signature> </TS_response>

FIG. 6A shows a logic flow diagram illustrating embodiments of a securefirmware transaction signing (SFTS) component for the SFTSP. In FIG. 6A,a SFTS API call may be obtained at 601. For example, the SFTS API callmay be obtained as a result of a call from a HSM associated with theSFTS component. It is to be understood that although the SFTS componentis described with regard to an API method to sign a transaction (e.g.,signMessageHash), in some embodiment, a variety of API methods may beavailable. In one embodiment, the following API methods may be availableto the HSM and/or to a TSS:

-   -   signMessageHash—this method receives a message hash and a        keychain path and returns an ECDSA signature value. Key        derivation steps are implemented by the SFTS component.        Temporary keys generated for signing are wiped out of the device        once the signing process is complete.        -   Input:            -   256-bit hash value to be signed            -   keychain path to be used for Bip32 key derivation        -   Output:            -   ECDSA signature in DER format    -   getAddressHash—this method returns a public Pay-to-Script-Hash        (P2SH) address generated for a given keychain path. SFTS        component code uses N extended master public keys stored inside        the HSM, generates N public keys corresponding to the provided        keychain path, and generates a Bitcoin address that can be used        for receiving funds.        -   Input:            -   keychain path to be used for Bip32 key derivation        -   Output:            -   P2SH hash value that can be converted by the requesting                application (e.g., client application) into a Bitcoin                address in the appropriate format (e.g., main Bitcoin                network, Testnet, etc.)

Transaction data may be determined at 605. In one implementation, thetransaction data may be provided in the SFTS API call and may include awallet identifier, a transaction hash, a keychain path, and/or the like.

A determination may be made whether a portable HSM is being utilized tosign the transaction. For example, a portable HSM may not be utilizedfor a hot wallet transaction. In another example, a portable HSM may beutilized for a cold wallet transaction. In one implementation, thisdetermination may be made by checking a setting associated with the HSM.

If a portable HSM is not being utilized, a master private key may beretrieved at 613. In one implementation, the master private key may bedetermined using a PKCS#11 function (e.g., C_FindObjectsInit( . . . )).In another implementation, the master private key may be determined viaan internal call on a HSM environment setting configured externally atHSM deployment time.

If a portable HSM is being utilized, an encrypted master private key maybe obtained at 617. In one implementation, the portable HSM may bequeried to obtain the encrypted private master key. For example, theprivate master key may be encrypted using a public key encryption key(e.g., associated with the HSM) stored by the portable HSM. A privatekey decryption key for the HSM may be retrieved at 621. In oneimplementation, the private key decryption key may be determined using aPKCS#11 function (e.g., C_FindObjectsInit( . . . )). In anotherimplementation, the private key decryption key may be determined via aninternal call on a HSM environment setting configured externally at HSMdeployment time.

Although one may choose to use the above to determine the master privatekey and/or the private key decryption key, in an alternative embodiment,the master private key and/or the private key decryption key may bedetermined via a MySQL database command (e.g., retrieved from a MySQLdatabase in tamper-proof storage).

The encrypted master private key may be decrypted at 625 using theretrieved private key decryption key.

A signing private key for the specified keychain path may be generatedat 629. In one implementation, the signing private key may be generatedin accordance with a deterministic key derivation procedure as describedin Bip32. The transaction may be signed at 633. In one implementation,the generated signing private key may be used to sign the transactionhash in accordance with the hashing algorithm utilized by the Bitcoinprotocol (e.g., RIPE160(SHA256 (SHA256 (message)))).

Temporary private key data may be wiped from memory at 637. In oneimplementation, the master private key obtained from the portable HSMand/or the generated signing private key may be wiped from memory of theHSM associated with the SFTS component. The signed transaction may bereturned at 641. In one implementation, the Elliptic Curve DigitalSignature Algorithm (ECDSA) signature in DER format may be returned.

FIG. 6B shows a logic flow diagram illustrating embodiments of atransaction server transaction signing (TSTS) component for the SFTSP.In FIG. 6B, a transaction signing request may be obtained at 602. Forexample, the transaction signing request may be obtained as a result ofa user utilizing a UI of a fund transfer CLI program to initiatetransaction signing (e.g., a fund transfer) using a master keyassociated with a hierarchical deterministic wallet.

A RSA public key may be requested from a HSM at 606. In oneimplementation, a public key request message may be sent to the HSM torequest the RSA public key.

A determination may be made at 608 whether the obtained RSA public keyis valid. For example, the fund transfer program may be configured towork with a specified set of HSMs, and the obtained RSA public key mayhave to be associated with one of the specified HSMs to be valid.

If the obtained RSA public key is not valid, an error message may begenerated at 618. For example, the error message may specify the errorthat occurred (e.g., RSA public key is not valid). A warning message maybe provided to the user and/or an action may be triggered at 620. In oneimplementation, a warning message based on the generated error messagemay be provided to the user to inform the user regarding the error. Inanother implementation, an action may be triggered based on a specifiedcondition (e.g., invalid RSA public key obtained three times). Forexample, the triggered action may be to erase data associated with thewallet. In another example, the triggered action may be to invalidatethe master key and to generate a new master key.

If the obtained RSA public key is valid, the RSA public key may beprovided to a portable HSM at 610. For example, the RSA public key maybe utilized by the portable HSM to encrypt a second master private keyshare stored by the portable HSM such that the corresponding RSA privatekey, available to the HSM, may be used to decrypt the second masterprivate key share. In one implementation, the RSA public key may beforwarded to the portable HSM via a master key share request message.

An encrypted second master private key share (e.g., for the specifiedwallet) may be requested from the portable HSM at 612. In oneimplementation, a master key share request message may be sent to theportable HSM to request the second master private key share encryptedwith the RSA public key.

A determination may be made at 614 whether the request for the encryptedsecond master private key share is authorized. In one implementation,one or more operators (e.g., based on M-of-N authentication) may have toapprove (e.g., via an authentication entry device associated with theportable HSM) the request to export the encrypted second master privatekey share from the portable HSM for the request to be authorized.

If the request for the encrypted second master private key share is notauthorized, an error message may be generated at 618. For example, theerror message may specify the error that occurred (e.g., request toexport the encrypted second master private key share from the portableHSM is not authorized). A warning message may be provided to the userand/or an action may be triggered at 620. In one implementation, awarning message based on the generated error message may be provided tothe user to inform the user regarding the error. In anotherimplementation, an action may be triggered based on a specifiedcondition (e.g., unauthorized request occurred three times). Forexample, the triggered action may be to erase data associated with thewallet. In another example, the triggered action may be to invalidatethe master key and to generate a new master key.

If the request for the encrypted second master private key share isauthorized, transaction signing may be requested from the HSM at 622. Inone implementation, a transaction signing request message may be sent tothe HSM to request transaction signing.

A transaction signing response may be provided to the client at 626. Inone implementation, a transaction signing response may be sent to theclient to inform the user whether the transaction signing was completedsuccessfully (e.g., via a UI of the fund transfer program).

FIG. 6C shows a logic flow diagram illustrating embodiments of a securefirmware transaction signing (SFTS) component for the SFTSP. In FIG. 6C,a public key request from a TSS may be obtained at 603. For example, thepublic key request may be obtained as a result of the TSS facilitatingtransaction signing.

A RSA key pair may be generated at 607. In one embodiment, a RSA keypair (e.g., a RSA public key and a corresponding RSA private key) may bepredefined (e.g., for a HSM). In one implementation, the RSA public keymay be determined using a PKCS#11 function (e.g., C_FindObjectsInit( . .. )). In another implementation, the RSA public key may be determinedvia an internal call on a HSM environment setting configured externallyat HSM deployment time. In an alternative implementation, the RSA publickey may be determined via a MySQL database command (e.g., retrieved froma MySQL database in tamper-proof storage). In another embodiment, a RSAkey pair may be generated dynamically (e.g., each time transactionsigning is executed). In one implementation, a RSA public key may begenerated using a PKCS#11 function (e.g., C_CreateObject( . . . )).

The RSA public key may be provided to the TSS at 611. In oneimplementation, the RSA public key may be provided to the TSS via apublic key response message.

A SFTS API call may be obtained at 615. For example, the SFTS API callmay be obtained as a result of a call from a HSM associated with theSFTS component. It is to be understood that although the SFTS componentis described with regard to an API method to sign a transaction (e.g.,signMessageHash), in some embodiment, a variety of API methods may beavailable. In one embodiment, the following API methods may be availableto the HSM and/or to a TSS:

-   -   signMessageHash—this method receives a message hash, a keychain        path and a handle to the transient object containing a second        master private key share (e.g., encrypted), and returns an ECDSA        signature value. Seed concatenation and key derivation steps are        implemented by the SFTS component. Temporary keys generated for        signing are wiped out of the device once the signing process is        complete.        -   Input:            -   256-bit hash value to be signed keychain path to be used                for Bip32 key derivation handle to the transient object                containing a second master private key share (e.g.,                encrypted)        -   Output:            -   ECDSA signature in DER format    -   getAddressHash—this method returns a public Pay-to-Script-Hash        (P2SH) address generated for a given keychain path. SFTS        component code uses N extended master public keys stored inside        the HSM, generates N public keys corresponding to the provided        keychain path, and generates a Bitcoin address that can be used        for receiving funds.        -   Input:            -   keychain path to be used for Bip32 key derivation        -   Output:            -   P2SH hash value that can be converted by the requesting                application (e.g., client application) into a Bitcoin                address in the appropriate format (e.g., main Bitcoin                network, Testnet, etc.)

An encrypted second master private key share utilized to recover amaster private key may be determined at 619. In one implementation, theencrypted second master private key share may be provided as an inputparameter in the SFTS API call.

A determination may be made at 623 whether the encrypted second masterprivate key share is decryptable. In one implementation, thisdetermination may be made by checking whether decrypting the encryptedsecond master private key share using the RSA private key results in avalid object.

If the encrypted second master private key share is not decryptable, anerror message may be generated at 627. For example, the error messagemay specify the error that occurred (e.g., second master private keyshare is not decryptable). A warning message may be provided to a userand/or an action may be triggered at 631. In one implementation, awarning message based on the generated error message may be provided tothe user (e.g., via the TSS) to inform the user regarding the error. Inanother implementation, an action may be triggered based on a specifiedcondition (e.g., non-decryptable second master private key shareobtained three times). For example, the triggered action may be to erasedata associated with an associated wallet. In another example, thetriggered action may be to invalidate the master key associated with thesecond master private key share and to generate a new master key.

If the encrypted second master private key share is decryptable, theencrypted second master private key share may be decrypted using the RSAprivate key at 635. In one implementation, the RSA private key may bedetermined using a PKCS#11 function (e.g., C_FindObjectsInit( . . . )).In another implementation, the RSA private key may be determined via aninternal call on a HSM environment setting configured externally at HSMdeployment time. In an alternative implementation, the RSA private keymay be determined via a MySQL database command (e.g., retrieved from aMySQL database in tamper-proof storage). In one implementation, theencrypted master key may be decrypted using a PKCS#11 function (e.g.,C_Decrypt( . . . )).

A first master private key share may be retrieved at 639. In oneimplementation, the first master private key share may be determinedusing a PKCS#11 function (e.g., C_FindObjectsInit( . . . )). In anotherimplementation, the first master private key share may be determined viaan internal call on a HSM environment setting configured externally atHSM deployment time. In an alternative implementation, the first masterprivate key share may be determined via a MySQL database command (e.g.,retrieved from a MySQL database in tamper-proof storage).

A master private key may be determined from master private key shares(e.g., from the first master private key share and the second masterprivate key share) at 643. In one embodiment, a method such as Shamir'sSecret Sharing may be utilized to recover the master private key fromthe master private key shares. See FIG. 14 for additional detailsregarding utilizing Shamir's Secret Sharing.

Transaction data may be determined at 647. In one implementation, thetransaction data may be provided in the SFTS API call and may include awallet identifier, a transaction identifier, a transaction hash, akeychain path, and/or the like.

A signing private key for the specified keychain path may be generatedusing the determined master private key at 651. In one implementation,the signing private key may be generated in accordance with adeterministic key derivation procedure as described in Bip32. Thetransaction may be signed at 655. In one implementation, the generatedsigning private key may be used to sign the transaction hash inaccordance with the hashing algorithm utilized by the Bitcoin protocol(e.g., RIPE160(SHA256(SHA256(message)))).

Temporary private key data may be wiped from memory at 659. In oneimplementation, the second master private key share obtained from theportable HSM, the determined master private key, and/or the generatedsigning private key may be wiped from memory of the HSM associated withthe SFTS component. The signed transaction may be returned at 663. Inone implementation, the ECDSA signature in DER format may be returned.

FIG. 7 shows an exemplary data model for the SFTSP. In one embodiment,the data model may be a Bip32 data model. In FIG. 7, a wallet composedof N (e.g., 3) master keys (or seeds) is shown. For each path, a pair ofprivate and public keys may be derived. A private key may be used forgenerating a signature; a public key may be used for a public addressfor receiving funds.

FIG. 8 shows an exemplary authentication model for the SFTSP. In FIG. 8,M-of-N authentication utilizing an HSM is illustrated. For example, inorder to start a highly sensitive business application operation (e.g.,transaction signing for a transfer of large funds between accounts, keybackup, key recovery), several physically present persons may have toauthenticate to the HSM. Physical presence is ensured by presenting aphysical authentication device, such as a smart card, token or encryptedkey on a USB device. In addition to the physical device, each personalso may have to authenticate using a password or PIN, which makes it amulti-factor authentication (MFA) process with the first factor being akey (something to have) and the second factor a PIN (something to know).This is schematically shown in FIG. 8 where two operators, each holdingan encrypted key on a USB memory stick, one after another insert theirUSB key into an authentication entry device attached to a HSM andconfirm their ownership of the key by entering a PIN associated with thekey in order to start a business application operation. Authenticationto the HSM may be tightly integrated in HSM firmware for access controland protection of key objects stored on the HSM through a key hierarchyof user keys on the USB token and master encryption keys on the HSM.

Security policy, defined for a business application and enforced on theHSM, contains a minimum number of persons that should successfullyauthenticate to the system out of a larger number of people that holdauthentication keys and PINs. If we have N operators with separate USBkeys and PINs but any M of them can authenticate to the system, this socalled M-of-N(or MoN) authentication policy covers such real lifesituations as two-person access control, work force rotation, leaves ofabsence, sickness, etc. See FIG. 9 for an example of validauthentication combinations for N=3 and M=2.

FIG. 9 shows an exemplary authentication use case for the SFTSP. In FIG.9, valid authentication combinations for N=3 and M=2 are illustrated. Asshown in FIG. 9, valid authentication combinations include: operator 1and operator 2, operator 2 and operator 3, and operator 1 and operator3.

FIG. 10 shows an exemplary key backup model for the SFTSP. In FIG. 10, aseed (e.g., master key) may be backed up using seed shares. The seed maybe generated and may be stored on a seed hosting HSM 1001 (e.g.,Gemalto's G5 HSM), which supports M-of-N authentication. For example,this may be done as part of a master key generation operation. A backuputility 1005 may request that a backup HSM 1010 (e.g., Gemalto'sProtectServer PCI-e HSM), which supports firmware module extensions andhosts SFTS module 1015, generate a RSA key pair and provide thegenerated public key. The backup utility may export the generated RSApublic key from the backup HSM and import it into the hosting HSM. Thebackup utility may request an export of the seed from the hosting HSMencrypted with the imported RSA public key. Operators may approve theseed export request by authenticating to an authentication entry deviceassociated with the hosting HSM (e.g., using 2-of-3 access controlenforcement). The backup utility may transfer the encrypted seed to thebackup HSM. The backup HSM may decrypt the seed using the previouslygenerated RSA private key and may create a local copy of the seed inmemory protected from external intrusion. The backup utility may utilizean API call to request seed shares, generated using an implementedsecret sharing method, from the backup HSM. See FIG. 14 for an exampleof a secret sharing method. The backup utility may print the providedseed shares (e.g., one at a time on a separate sealed tamper-protectedform), and the printed seed shares may be distributed for storage ingeographically distributed locations in order to avoid the recovery of acomplete seed from shares available at any single location. Thus, thefull seed is not exposed in decrypted form outside of an HSM device(e.g., in RAM of the host workstation) during the key backup process,which eliminates the risk of memory-attack theft. As seed shares may bebacked up separately (e.g., on paper in bank safety boxes), multi-personaccess control and segmentation is further enforced.

FIGS. 11A-B show a datagraph diagram illustrating embodiments of a dataflow for the SFTSP. In FIGS. 11A-B, a user of a SFTSP client 1102 maysend a key backup request 1121 to a backup utility 1106 to facilitatekey backup (e.g., of a master key associated with a hierarchicaldeterministic wallet). For example, the SFTSP client may be a desktop, alaptop, a tablet, a smartphone, and/or the like that is executing thebackup utility. In one implementation, the key backup request mayinclude parameters specified by the user (e.g., via a user interface(UI) of the backup utility) such as a request type (e.g., backup masterkey, recover master key), a wallet identifier (e.g., of the wallet whosemaster key should be backed up), the number of master key shares togenerate, the number of master key shares sufficient to recover themaster key, and/or the like.

A backup utility key backup (BUKB) component 1125 may utilize parametersprovided in the key backup request to facilitate generation of backupmaterials for the relevant master key (e.g., for the specified wallet).See FIG. 12 for additional details regarding the BUKB component.

The backup utility may send a public key request message 1129 to abackup HSM 1110 to request a RSA public key from the backup HSM. In oneimplementation, the public key request message may include data such asa request identifier, a backup request identifier, and/or the like. Inone embodiment, the backup utility may provide the following examplepublic key request message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /public_key_request_message.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <public_key_request_message><request_identifier>ID_request_11</request_identifier><backup_request_identifier>ID_backup_request_1</backup_request_identifier></public_key_request_message>

The backup HSM may provide a RSA public key to the backup utility via apublic key response message 1133. In one implementation, the public keyresponse message may include data such as a response identifier, abackup request identifier, a RSA public key, and/or the like. In oneembodiment, the backup HSM may provide the following example public keyresponse message, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /public_key_response_message.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <public_key_response_message><response_identifier>ID_response_11</response_identifier><backup_request_identifier>ID_backup_request_1</backup_request_identifier><RSA_public_key>RSA public key provided by the backupHSM</RSA_public_key> </public_key_response_message>

The backup utility may send a master key request message 1137 to ahosting HSM 1114 to request an encrypted master key (e.g., for thespecified wallet) from the hosting HSM. In one implementation, themaster key request message may include data such as a requestidentifier, a backup request identifier, a wallet identifier, a RSApublic key, and/or the like. In one embodiment, the backup utility mayprovide the following example master key request message, substantiallyin the form of a HTTP(S) POST message including XML-formatted data, asprovided below:

POST /master_key_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_request_message><request_identifier>ID_request_12</request_identifier><backup_request_identifier>ID_backup_request_1</backup_request_identifier><wallet_identifier>ID_Wallet1</wallet_identifier> <RSA_public_key>RSApublic key provided by the backup HSM</RSA_public_key></master_key_request_message>

The hosting HSM may provide the encrypted master key to the backuputility via a master key response message 1141. In one implementation,the master key response message may include data such as a responseidentifier, a backup request identifier, a wallet identifier, anencrypted master key, and/or the like. In one embodiment, the hostingHSM may provide the following example master key response message,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /master_key_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_response_message><response_identifier>ID_response_12</response_identifier><backup_request_identifier>ID_backup_request_1</backup_request_identifier><wallet_identifier>ID_Wallet1</wallet_identifier> <master_key>encryptedmaster key provided by the hosting HSM</master_key></master_key_response_message>

The backup utility may send a key backup request message 1145 to thebackup HSM to request master key shares for the encrypted master keyfrom the backup HSM. In one implementation, the key backup requestmessage may include data such as a request identifier, a request type, abackup request identifier, an encrypted master key, the number of masterkey shares to generate, the number of master key shares sufficient torecover the master key, and/or the like. In one embodiment, the backuputility may provide the following example key backup request message,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /key_backup_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <key_backup_request_message><request_identifier>ID_request_13</request_identifier><request_type>BACKUP_MASTER_KEY</request_type><backup_request_identifier>ID_backup_request_1</backup_request_identifier><master_key>encrypted master key provided by the hostingHSM</master_key><number_of_shares_to_generate>4</number_of_shares_to_generate><number_of_shares_sufficient_to_recover>2</number_of_shares_sufficient_to_recover></key_backup_request_message>

The backup HSM may make a key backup API call 1149 to a SFTS module 1118to request that the SFTS module generate master key shares. In oneimplementation, the key backup API call may include data such as arequest type (e.g., backup master key, recover master key), an encryptedmaster key, the number of master key shares to generate, the number ofmaster key shares sufficient to recover the master key, and/or the like.

Data provided in the key backup API call may be used by a securefirmware key backup (SFKB) component 1153 to generate master key shares.See FIG. 13 for additional details regarding the SFKB component.

The SFTS module may send key backup response data 1157 to the backup HSMin response to the key backup API call. In one implementation, the keybackup response data may include the generated master key shares.

The backup HSM may send a key backup response message 1161 to the backuputility. In one implementation, the key backup response message mayinclude data such as a response identifier, a backup request identifier,generated master key shares, and/or the like. For example, data providedin the key backup response message may be utilized by the backup utilityto facilitate printing and/or distributing the generated master keyshares. In one embodiment, the backup HSM may provide the followingexample key backup response message, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /key_backup_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <key_backup_response_message><response_identifier>ID_response_13</response_identifier><backup_request_identifier>ID_backup_request_1</backup_request_identifier><master_key_shares><share>0_1D7927D78EAD692BB1694497180C66B3E88676F22B920625EDECAA1728F2921E5E309297B76FE658B61DF9D501B49FB553255DFDC8FE966F2950DDD0078C809B02</share><share>1_01658051EB654BBD692013E6E5FB6BA2D9C36980AE0D592D4D07516910646EE05B223C3C13C1DF6736232724DF32644791E4A1217DD642C8A7C0A240311DBD1172FE</share><share>2_0191E6488B7976C0C147B244239459E2FF3DA2C64B554B9F215D1D6E8261B9F8D9A1E78AC218260A8EEFCBD56A1BAE4E68A7F53DB2103AA70FBC070E8B0BFF414147</share><share>3_01B2D2F13EBB73D1B486D84BA81B173D99AB2F56322452CDF97459965513F74F5F7DD92EE1084F8847CBDA9FE118A133FEC788513A70C8B1343502C3C309052568E5</share></master_key_shares> </key_backup_response_message>

The backup utility may send a key backup response 1165 to the user. Forexample, the key backup response may be used to inform the user whetherthe key backup was completed successfully (e.g., via a UI of the backuputility).

FIG. 12 shows a logic flow diagram illustrating embodiments of a backuputility key backup (BUKB) component for the SFTSP. In FIG. 12, a keybackup request may be obtained at 1201. For example, the key backuprequest may be obtained as a result of a user utilizing a UI of a backuputility to initiate key backup of a master key associated with ahierarchical deterministic wallet. See FIG. 17 for an example of a UIthat may be utilized by the user.

A RSA public key may be requested from a backup HSM at 1205. In oneimplementation, a public key request message may be sent to the backupHSM to request the RSA public key.

A determination may be made at 1207 whether the obtained RSA public keyis valid. For example, the backup utility may be configured to work witha specified set of backup HSMs, and the obtained RSA public key may haveto be associated with one of the specified backup HSMs to be valid.

If the obtained RSA public key is not valid, an error message may begenerated at 1217. For example, the error message may specify the errorthat occurred (e.g., RSA public key is not valid). A warning message maybe provided to the user and/or an action may be triggered at 1219. Inone implementation, a warning message based on the generated errormessage may be provided to the user to inform the user regarding theerror. In another implementation, an action may be triggered based on aspecified condition (e.g., invalid RSA public key obtained three times).For example, the triggered action may be to erase data associated withthe wallet. In another example, the triggered action may be toinvalidate the master key and to generate a new master key.

If the obtained RSA public key is valid, the RSA public key may beprovided to a hosting HSM at 1209. For example, the RSA public key maybe utilized by the hosting HSM to encrypt the master key hosted by thehosting HSM such that the corresponding RSA private key, available tothe backup HSM, may be used to decrypt the master key. In oneimplementation, the RSA public key may be forwarded to the hosting HSMvia a master key request message.

An encrypted master key (e.g., for the specified wallet) may berequested from the hosting HSM at 1211. In one implementation, a masterkey request message may be sent to the hosting HSM to request the masterkey encrypted with the RSA public key.

A determination may be made at 1213 whether the request for theencrypted master key is authorized. In one implementation, one or moreoperators (e.g., based on M-of-N authentication) may have to approve(e.g., via an authentication entry device associated with the hostingHSM) the request to export the encrypted master key from the hosting HSMfor the request to be authorized.

If the request for the encrypted master key is not authorized, an errormessage may be generated at 1217. For example, the error message mayspecify the error that occurred (e.g., request to export the encryptedmaster key from the hosting HSM is not authorized). A warning messagemay be provided to the user and/or an action may be triggered at 1219.In one implementation, a warning message based on the generated errormessage may be provided to the user to inform the user regarding theerror. In another implementation, an action may be triggered based on aspecified condition (e.g., unauthorized request occurred three times).For example, the triggered action may be to erase data associated withthe wallet. In another example, the triggered action may be toinvalidate the master key and to generate a new master key.

If the request for the encrypted master key is authorized, master keyshares for the master key may be requested from the backup HSM at 1221.In one implementation, a key backup request message may be sent to thebackup HSM to request generation of master key shares. For example, thekey backup request message may specify how many master key shares togenerate and/or how many master key shares should be sufficient torecover the master key.

Generation of backup materials may be facilitated at 1225. In variousimplementations, the provided master key shares may be backed up usingbackup materials such as paper printouts, metal or plastic plates (e.g.,Cryptosteel), USB keys, hard drives, solid state drives, portable HSMs,and/or the like. For example, the provided master key shares may beprinted out (e.g., one at a time on a separate sealed tamper-evidentform). See FIG. 15 for an example of a tamper-evident paper form. Thebackup materials may be distributed for storage in geographicallydistributed locations. In some implementations, a hybrid combination ofseveral backup materials may be used (e.g., 4 paper copies, 4 USB keysand 4 portable HSM devices). For example, each geographic backuplocation may store a mixture of different types of backup materials ormaterials of just one type. See FIG. 16A for an example of how theprovided master key shares may be distributed and stored geographically.In some implementations, the SFTSP may be configured to requirespecified types of backup materials to recover the master key. Forexample, two master key shares stored on physical backup materials andtwo master key shares stored on digital backup materials may be requiredto recover the master key. See FIG. 16B for an example of backupmaterials that may be utilized to recover the master key.

FIG. 13 shows a logic flow diagram illustrating embodiments of a securefirmware key backup (SFKB) component for the SFTSP. In FIG. 13, a publickey request from a backup utility may be obtained at 1301. For example,the public key request may be obtained as a result of the backup utilityexecuting a key backup.

A RSA key pair may be generated at 1305. In one embodiment, a RSA keypair (e.g., a RSA public key and a corresponding RSA private key) may bepredefined (e.g., for a backup HSM). In one implementation, the RSApublic key may be determined using a PKCS#11 function (e.g.,C_FindObjectsInit( . . . )). In another implementation, the RSA publickey may be determined via an internal call on a backup HSM environmentsetting configured externally at HSM deployment time. In an alternativeimplementation, the RSA public key may be determined via a MySQLdatabase command (e.g., retrieved from a MySQL database in tamper-proofstorage). In another embodiment, a RSA key pair may be generateddynamically (e.g., each time a key backup is executed). In oneimplementation, a RSA public key may be generated using a PKCS#11function (e.g., C_CreateObject( . . . )).

The RSA public key may be provided to the backup utility at 1309. In oneimplementation, the RSA public key may be provided to the backup utilityvia a public key response message.

A key backup API call may be obtained at 1313. For example, the keybackup API call may be obtained as a result of a call from the backupHSM (e.g., based on receiving a key backup request message from thebackup utility) associated with the SFKB component. In one embodiment,the following API method may be available to the backup HSM and/or tothe backup utility:

-   -   SplitSeed—this method receives a master key value, 512-bit        number, and returns an array of master key secret shares.        Generation of master key shares is implemented by the SFKB        component. Temporary materials, including the decrypted master        key value, are wiped out of the device once the master key        shares generation process is complete.        -   Input:            -   512-bit master key value encrypted with an RSA public                key generated by the backup HSM        -   Output:            -   full array of 256-bit master key shares (N master key                shares)

In one implementation, a C implementation of this method for M-of-N keysplit may have the following interface:

SplitSeed(CK_ULONG slot_id, const char *pin, CK_OBJECT_HANDLE hSeed,CK_ULONG rec_shares_num, CK_ULONG backup_shares_num, CK_BYTE_PTRpRng_seed, CK_ULONG rng_seed_len, CK_BYTE_PTR *ppShares, CK_ULONG_PTRpShares_len);

The following table describes input and output parameters:

Input/ Sample Name Output Type Description Values slot_id In CK_ULONGIdentifier of the target slot inside HSM 0 pin In const char* User tokenPIN for HSM 0123 hSeed In CK_OBJECT_HANDLE Handle value of the masterkey 1000 rec_shares_num In CK_ULONG Number of recovery shares (M)sufficient 4 to recover the original seed. backup_shares_num In CK_ULONGNumber of backup shares (N) to be 12 generated. pRng_seed In CK_BYTE_PTRPointer to a byte array containing an initialization seed for the randomnumber generator rng_seed_len In CK_ULONG Length of the array containingan 64 initialization seed for the random number generator ppShares OutCK_BYTE_PTR * Pointer to the pointer to a byte array containing thegenerated secret shares pShares_len Out CK_ULONG_PTR Pointer to a longnumber containing the 64 length of the byte array containing thegenerated secret shares

An encrypted master key for which master key shares should be generatedmay be determined at 1317. In one implementation, the encrypted masterkey may be provided as an input parameter in the key backup API call.

A determination may be made at 1321 whether the encrypted master key isdecryptable. In one implementation, this determination may be made bychecking whether decrypting the encrypted master key using the RSAprivate key results in a valid object.

If the encrypted master key is not decryptable, an error message may begenerated at 1325. For example, the error message may specify the errorthat occurred (e.g., master key is not decryptable). A warning messagemay be provided to a user and/or an action may be triggered at 1327. Inone implementation, a warning message based on the generated errormessage may be provided to the user (e.g., via the backup utility) toinform the user regarding the error. In another implementation, anaction may be triggered based on a specified condition (e.g.,non-decryptable master key obtained three times). For example, thetriggered action may be to erase data associated with a wallet. Inanother example, the triggered action may be to invalidate the masterkey and to generate a new master key.

If the encrypted master key is decryptable, the encrypted master key maybe decrypted using the RSA private key at 1329. In one implementation,the encrypted master key may be decrypted using a PKCS#11 function(e.g., C_Decrypt( . . . )).

The number of master key shares to generate and/or the number of masterkey shares that should be sufficient to recover the master key may bedetermined at 1333. In one implementation, this data may be provided asinput parameters in the key backup API call.

Master key shares for the master key may be generated at 1337. In oneembodiment, a method such as Shamir's Secret Sharing may be utilized togenerate master key shares based on the specified number of master keyshares to generate and/or the specified number of master key shares thatshould be sufficient to recover the master key. See FIG. 14 foradditional details regarding utilizing Shamir's Secret Sharing. In oneimplementation, the generated master key shares may take on thefollowing form (e.g., in hexadecimal format):

0_1D7927D78EAD692BB1694497180C66B3E88676F22B920625EDECAA1728F2921E5E309297B76FE658B61DF9D501B49FB553255DFDC8FE966F2950DDD0078C809B021_01658051EB654BBD692013E6E5FB6BA2D9C36980AE0D592D4D07516910646EE05B223C3C13C1DF6736232724DF32644791E4A1217DD642C8A7C0A240311DBD1172FE2_0191E6488B7976C0C147B244239459E2FF3DA2C64B554B9F215D1D6E8261B9F8D9A1E78AC218260A8EEFCBD56A1BAE4E68A7F53DB2103AA70FBC070E8B0BFF4141473_01B2D2F13EBB73D1B486D84BA81B173D99AB2F56322452CDF97459965513F74F5F7DD92EE1084F8847CBDA9FE118A133FEC788513A70C8B1343502C3C309052568E5 Where 0_, ..., 3_designate a master key share's index and the rest is its value.

The generated master key shares may be provided to the backup utility at1341. In one implementation, the master key shares may be returned tothe backup HSM as the output of the key backup API call, and/or thebackup HSM may provide the master key shares to the backup utility via akey backup response message.

FIG. 14 shows a screenshot diagram illustrating embodiments of theSFTSP. In FIG. 14, Shamir's Secret Sharing method that may be utilizedfor secret sharing and/or secret recovery is illustrated. Shamir'sSecret Sharing is based on the generic algebraic fact that knowing Ndifferent points is sufficient to recover a polynomial of the order ofN—1. For example, two points on a coordinate plane define a line on thatplane. As shown in FIG. 14, this may be used to generate several secretshares any pair of which can be used to restore the original secret.

For a seed value S, a point with coordinates (0, S) may be chosen (i.e.,a point on the Y axis). A second point R with coordinates (X, Y) may berandomly generated (e.g., using two random numbers X and Y). Togetherthis random point (X, Y) and point (0, S) define a line on thecoordinate plane. Any number (e.g., the specified number of master keyshares to generate) of points (e.g., any four points) on this line maybe selected to become the secret shares—each point by itself does notreveal any information about the original number S. However, any pair ofsuch points fully recovers the original line whose Y-intercept gives theseed value S.

In one implementation, in order to reduce the size of the backup keymaterials used in calculations, a pre-determined set of X-coordinatevalues (e.g., 10², 10⁴, 10⁶, 10⁸) may be used for the shares and theY-coordinates may be referred to by their indices in the range (e.g., [0. . . 3]).

In implementations where more than two points (e.g., three points) arespecified as being sufficient to recover the seed value S, Lagrangeinterpolation of polynomials may be utilized to generate secret sharesand/or to recover the seed value.

FIG. 15 shows a screenshot diagram illustrating embodiments of theSFTSP. In FIG. 15, a sample printed copy of concealed secret share'sdata on a tamper-evident paper form is illustrated.

FIG. 16A shows an exemplary seed shares geographic distribution modelfor the SFTSP. In FIG. 16A, a schematic diagram of how generated seedshares may be distributed and stored geographically is shown. Eachsecret share backup material output (e.g., for the four generated secretshares) is distributed to a different geographic location and storedthere in a secure location (e.g., a bank's vault).

For a seed recovery using 2-of-4 backup scheme, two shares from any twolocations are sufficient to recover the seed. Similarly, in order tosteal the seed, an attacker would have to successfully compromise atleast two storage locations, which is more complicated than a singlestorage location. The seed becomes unrecoverable if at least threeshares are completely destroyed, which is very unlikely even in case ofa major disaster recovery.

FIG. 16B shows an exemplary seed shares implementation case for theSFTSP. In FIG. 16B, the SFTSP may be configured to require two masterkey shares stored on physical backup materials and two master key sharesstored on digital backup materials to recover a master key 1601.Examples of physical backup materials that may be utilized include ascroll 1605, a stone table 1610, a piece of paper 1615, and/or the like.Examples of digital backup materials that may be utilized include abarcode shown on a smartphone 1620, a QR code shown on a smartwatch1625, a file 1630, an encrypted file 1635, and/or the like. In oneimplementation, the SFTSP may be configured to require the use of anyphysical backup materials and/or any digital backup materials. Inanother implementation, the SFTSP may be configured to require the useof specified physical backup materials (e.g., one master key sharestored on paper and one master key share stored on a stone tablet)and/or specified digital backup materials (e.g., one master key sharestored in a QR code on a smartwatch and one master key share stored inan encrypted file).

FIG. 17 shows a screenshot diagram illustrating embodiments of theSFTSP. In FIG. 17, an exemplary interactive command-line interface (CLI)of a backup utility is illustrated. In one implementation, upongenerating a master key on a HSM, the master key may be split intomaster key shares inside the HSM. Each share may be exported to anair-gapped key-generation workstation and printed out one at a time suchthat the shares are not in the workstation's RAM at the same time.

FIG. 18 shows an exemplary key recovery model for the SFTSP. In FIG. 18,a seed (e.g., master key) may be recovered from seed shares. Seed sharesutilized to recover the seed (e.g., a minimum number of seed shares) maybe transferred from their storage locations to a recovery center.Operators participating in the key recovery process may enter the seedshares into a reading device 1820 (e.g., each operator may hold andenter a single seed via a barcode reader, keyboard, USB drive, harddrive, portable HSM, etc.), and the reading device may transfer the seedshares to a recovery utility 1805. The recovery utility may request thata seed hosting HSM 1801 (e.g., Gemalto's G5 HSM), which will host therecovered seed and which supports M-of-N authentication, generate a RSAkey pair and provide the generated public key. Operators may approve thekey pair generation and seed recovery process by authenticating to anauthentication entry device associated with the hosting HSM (e.g., using2-of-3 access control enforcement). The recovery utility may export thegenerated RSA public key from the hosting HSM and import it into abackup HSM 1810 (e.g., Gemalto's ProtectServer PCI-e HSM), whichsupports firmware module extensions and hosts SFTS module 1815. Therecovery utility may utilize an API call to provide the entered seedshares to the backup HSM and to request recovery of the seed from theprovided shares. The backup HSM may recover the seed using animplemented secret recovery method. See FIG. 14 for an example of asecret recovery method. The backup HSM may encrypt the recovered seedusing the provided RSA public key and may return the encrypted seed tothe recovery utility. The recovery utility may transfer the encryptedseed to the hosting HSM. The hosting HSM may decrypt the seed using thepreviously generated RSA private key and may store the seed in thehosting HSM. Thus, the full seed is not exposed in decrypted formoutside of an HSM device (e.g., in RAM of the host workstation) duringthe key recovery process, which eliminates the risk of memory-attacktheft. As M-of-N shares may be utilized to recover the seed, theredundancy of backup stores is further increased. For example, in a2-of-4 backup scheme, 4 shares may be stored at four regions separately.If one or two regions are destroyed, shares from the other two regionscan still be used to recover the full seed.

FIG. 19 shows a datagraph diagram illustrating embodiments of a dataflow for the SFTSP. In FIG. 19, a user of a SFTSP client 1902 may send akey recovery request 1921 to a recovery utility 1906 to facilitate keyrecovery (e.g., of a master key associated with a hierarchicaldeterministic wallet). For example, the SFTSP client may be a desktop, alaptop, a tablet, a smartphone, and/or the like that is executing therecovery utility (e.g., the recovery utility may be the same applicationas the backup utility or a separate application). In one implementation,the key recovery request may include parameters specified by the user(e.g., via a UI of the recovery utility) such as a request type (e.g.,backup master key, recover master key), a wallet identifier (e.g., ofthe wallet whose master key should be recovered), the number of masterkey shares sufficient to recover the master key, master key shares(e.g., entered via a reading device), and/or the like.

A recovery utility key recovery (RUKR) component 1925 may utilizeparameters provided in the key recovery request to facilitate recoveryof the relevant master key (e.g., for the specified wallet). See FIG. 20for additional details regarding the RUKR component.

The recovery utility may send a public key request message 1929 to ahosting HSM 1914 to request a RSA public key from the hosting HSM. Inone implementation, the public key request message may include data suchas a request identifier, a recovery request identifier, and/or the like.In one embodiment, the recovery utility may provide the followingexample public key request message, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /public_key_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <public_key_request_message><request_identifier>ID_request_21</request_identifier><recovery_request_identifier>ID_recovery_request_1</recovery_request_identifier></public_key_request_message>

The hosting HSM may provide a RSA public key to the recovery utility viaa public key response message 1933. In one implementation, the publickey response message may include data such as a response identifier, arecovery request identifier, a RSA public key, and/or the like. In oneembodiment, the hosting HSM may provide the following example public keyresponse message, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /public_key_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <public_key_response_message><response_identifier>ID_response_21</response_identifier><recovery_request_identifier>ID_recovery_request_1</recovery_request_identifier><RSA_public_key>RSA public key provided by the hostingHSM</RSA_public_key> </public_key_response_message>

The recovery utility may send a key recovery request message 1937 to abackup HSM 1910 to request recovery of a master key (e.g., for thespecified wallet) from the backup HSM. In one implementation, the keyrecovery request message may include data such as a request identifier,a request type, a recovery request identifier, a RSA public key, thenumber of master key shares sufficient to recover the master key, masterkey shares, and/or the like. In one embodiment, the recovery utility mayprovide the following example key recovery request message,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /key_recovery_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <key_recovery_request_message><request_identifier>ID_request_22</request_identifier><request_type>RECOVER_MASTER_KEY</request_type><recovery_request_identifier>ID_recovery_request_1</recovery_request_identifier><RSA_public_key>RSA public key provided by the hostingHSM</RSA_public_key><number_of_shares_sufficient_to_recover>2</number_of_shares_sufficient_to_recover><master_key_shares><share>0_1D7927D78EAD692BB1694497180C66B3E88676F22B920625EDECAA1728F2921E5E309297B76FE658B61DF9D501B49FB553255DFDC8FE966F2950DDD0078C809B02</share><share>1_01658051EB654BBD692013E6E5FB6BA2D9C36980AE0D592D4D07516910646EE05B223C3C13C1DF6736232724DF32644791E4A1217DD642C8A7C0A240311DBD1172FE</share></master_key_shares> </key_recovery_request_message>

The backup HSM may make a key recovery API call 1941 to a SFTS module1918 to request that the SFTS module recover the master key from themaster key shares. In one implementation, the key recovery API call mayinclude data such as a request type (e.g., backup master key, recovermaster key), a RSA public key, the number of master key sharessufficient to recover the master key, master key shares, and/or thelike.

Data provided in the key recovery API call may be used by a securefirmware key recovery (SFKR) component 1945 to recover the master keyfrom the master key shares. See FIG. 21 for additional details regardingthe SFKR component.

The SFTS module may send key recovery response data 1949 to the backupHSM in response to the key recovery API call. In one implementation, thekey recovery response data may include an encrypted recovered masterkey.

The backup HSM may send a key recovery response message 1953 to therecovery utility. In one implementation, the key recovery responsemessage may include data such as a response identifier, a recoveryrequest identifier, the encrypted recovered master key, and/or the like.In one embodiment, the backup HSM may provide the following example keyrecovery response message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /key_recovery_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <key_recovery_response_message><response_identifier>ID_response_22</response_identifier><recovery_request_identifier>ID_recovery_request_1</recovery_request_identifier><master_key>encrypted recovered master key provided by the backupHSM</master_key> </key_recovery_response_message>

The recovery utility may send a master key import message 1957 to thehosting HSM to import the recovered master key into the hosting HSM. Inone implementation, the master key import message may include data suchas a request identifier, a recovery request identifier, a walletidentifier, the encrypted recovered master key, and/or the like. Forexample, the hosting HSM may decrypt and/or store the recovered masterkey for the specified wallet. In one embodiment, the recovery utilitymay provide the following example master key import message,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /master_key_import_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_import_message><request_identifier>ID_request_23</request_identifier><recovery_request_identifier>ID_recovery_request_1</recovery_request_identifier><wallet_identifier>ID_Wallet1</wallet_identifier> <master_key>encryptedrecovered master key provided by the backup HSM</master_key></master_key_import_message>

The recovery utility may send a key recovery response 1961 to the user.For example, the key recovery response may be used to inform the userwhether the key recovery was completed successfully (e.g., via a UI ofthe recovery utility).

FIG. 20 shows a logic flow diagram illustrating embodiments of arecovery utility key recovery (RUKR) component for the SFTSP. In FIG.20, a key recovery request may be obtained at 2001. For example, the keyrecovery request may be obtained as a result of a user utilizing a UI ofa recovery utility to initiate key recovery of a master key associatedwith a hierarchical deterministic wallet. See FIG. 22 for an example ofa UI that may be utilized by the user.

Master key shares utilized to recover the master key (e.g., a minimumnumber of master key shares sufficient to recover the master key) may beobtained at 2005. In one implementation, the master key shares may beobtained from operators participating in the key recovery process via areading device. In one implementation, the master key shares may beforwarded to a backup HSM via a key recovery request message.

A RSA public key may be requested from a hosting HSM at 2009. In oneimplementation, a public key request message may be sent to the hostingHSM to request the RSA public key.

A determination may be made at 2011 whether the obtained RSA public keyis valid. For example, the recovery utility may be configured to workwith a specified set of hosting HSMs, and the obtained RSA public keymay have to be associated with one of the specified hosting HSMs to bevalid.

If the obtained RSA public key is not valid, an error message may begenerated at 2017. For example, the error message may specify the errorthat occurred (e.g., RSA public key is not valid). A warning message maybe provided to the user and/or an action may be triggered at 2019. Inone implementation, a warning message based on the generated errormessage may be provided to the user to inform the user regarding theerror. In another implementation, an action may be triggered based on aspecified condition (e.g., invalid RSA public key obtained three times).For example, the triggered action may be to erase data associated withthe wallet. In another example, the triggered action may be toinvalidate the master key and to generate a new master key.

If the obtained RSA public key is valid, a determination may be made at2013 whether the key recovery request is authorized. In oneimplementation, one or more operators (e.g., based on M-of-Nauthentication) may have to approve (e.g., via an authentication entrydevice associated with the hosting HSM) the request to recover themaster key and to import it into the hosting HSM.

If the key recovery request is not authorized, an error message may begenerated at 2017. For example, the error message may specify the errorthat occurred (e.g., key recovery request is not authorized). A warningmessage may be provided to the user and/or an action may be triggered at2019. In one implementation, a warning message based on the generatederror message may be provided to the user to inform the user regardingthe error. In another implementation, an action may be triggered basedon a specified condition (e.g., unauthorized request occurred threetimes). For example, the triggered action may be to erase dataassociated with the wallet. In another example, the triggered action maybe to invalidate the master key and to generate a new master key.

If the key recovery request is authorized, the RSA public key may beprovided to the backup HSM at 2021. For example, the RSA public key maybe utilized by the backup HSM to encrypt the recovered master key suchthat the corresponding RSA private key, available to the hosting HSM,may be used to decrypt the recovered master key. In one implementation,the RSA public key may be forwarded to the backup HSM via the keyrecovery request message.

The encrypted recovered master key (e.g., for the specified wallet) maybe obtained from the backup HSM at 2025. In one implementation, theencrypted recovered master key may be obtained via a key recoveryresponse message sent by the backup HSM.

The encrypted master key may be provided to the hosting HSM at 2029. Forexample, the hosting HSM may decrypt and/or store the recovered masterkey for the specified wallet. In one implementation, the encryptedmaster key may be forwarded to the hosting HSM via a master key importmessage.

FIG. 21 shows a logic flow diagram illustrating embodiments of a securefirmware key recovery (SFKR) component for the SFTSP. In FIG. 21, a keyrecovery API call may be obtained at 2101. For example, the key recoveryAPI call may be obtained as a result of a call from a backup HSM (e.g.,based on receiving a key recovery request message from a recoveryutility) associated with the SFKR component. In one embodiment, thefollowing API method may be available to the backup HSM and/or to therecovery utility:

-   -   CombineSeedShares—this method returns a 512-bit master key value        restored from provided master key shares and encrypted with an        RSA public key generated by the hosting HSM. The SFKR component        uses provided master key shares to restore the full master key        value according to the secret sharing algorithm used in the        implementation.        -   Input:            -   subarray of master key shares sufficient to recover the                master key (M master key shares)        -   Output:            -   512-bit master key value encrypted with an RSA public                key generated by the hosting HSM

In one implementation, a C implementation of this method for M-of-N keysplit may have the following interface:

CombineSeedShares(CK_ULONG slot_id, const char *pin, CK_BYTE_PTRpShares, CK_ULONG shares_num, CK_BYTE_PTR *phSeed, CK_ULONG_PTRphSeed_len)

The following table describes input and output parameters:

Input/ Sample Name Output Type Description Values slot_id In CK_ULONGIdentifier of the target slot inside HSM 0 pin In const char* User PINfor HSM 0123 pShares In CK_BYTE_PTR Pointer to the byte array containingthe list of secret shares along with their indices shares_num InCK_ULONG Number of secret shares submitted for master key 5 recoveryphSeed Out CK_BYTE_PTR * Pointer to the pointer to a byte arraycontaining the handle to the recovered full master key phSeed_len OutCK_ULONG_PTR Pointer to a long number containing the length of the bytearray containing the handle to the recovered master key

The number of master key shares to use (e.g., the number of master keyshares sufficient to recover the master key) may be determined at 2105.In one implementation, this data may be provided as an input parameterin the key recovery API call. In another implementation, thisdetermination may be made via an internal call on a HSM environmentsetting.

The provided master key shares may be determined at 2109. In oneimplementation, this data may be provided as input parameters in the keyrecovery API call.

A determination may be made at 2113 whether the correct number of masterkey shares was provided. In one implementation, this determination maybe made by checking whether the number of provided master key sharesmatches the number of master key shares to use.

If an incorrect number of master key shares was provided, an errormessage may be generated at 2117. For example, the error message mayspecify the error that occurred (e.g., incorrect number of master keyshares is provided). A warning message may be provided to a user and/oran action may be triggered at 2119. In one implementation, a warningmessage based on the generated error message may be provided to the user(e.g., via the recovery utility) to inform the user regarding the error.In another implementation, an action may be triggered based on aspecified condition (e.g., incorrect number of master key sharesprovided three times). For example, the triggered action may be to erasedata associated with the wallet. In another example, the triggeredaction may be to invalidate the master key and to generate a new masterkey.

If the correct number of master key shares is provided, a master key maybe recovered from the provided master key shares at 2121. In oneembodiment, a method such as Shamir's Secret Sharing may be utilized torecover the master key from the master key shares based on the specifiednumber of master key shares to use. See FIG. 14 for additional detailsregarding utilizing Shamir's Secret Sharing. For example, in a 2-of-4backup scheme, any arbitrary two shares can be used to reconstruct theoriginal full master key.

The provided RSA public key may be determined at 2125. In oneimplementation, the RSA public key may be provided as an input parameterin the key recovery API call.

The recovered master key may be encrypted using the RSA public key at2129. In one implementation, the recovered master key may be encryptedusing a PKCS#11 function (e.g., C_Encrypt( . . . )).

The encrypted recovered master key may be provided to the recoveryutility at 2133. In one implementation, the encrypted recovered masterkey may be provided to the recovery utility via a key recovery responsemessage.

FIG. 22 shows a screenshot diagram illustrating embodiments of theSFTSP. In FIG. 22, an exemplary interactive CLI of a recovery utility isillustrated. In one implementation, recovery of a master key may involveseveral users (operators) who authenticate to the involved devices usingmulti-factor authentication. For example, master key shares' indices andvalues may have to be manually entered (e.g., twice).

FIG. 23 shows an exemplary architecture for the SFTSP. As shown in FIG.23, in various embodiments, an Ethereum EOA master private key is splitinto multiple key shares (e.g., via Shamir's Secret Sharing) which arestored and protected across multiple HSMs. For example, Shamir's SecretSharing may be implemented as a custom firmware functional module (FM)(e.g., a SFTS module) on a designated HSM device such that attransaction signing runtime the HSM securely reconstructs key shares(e.g., with some stored on other HSM devices) back into a transient fullprivate key on the HSM. When key shares are created (e.g., from a masterprivate key in a key-generation ceremony), one share may be marked asnon-extractable on the designated HSM device where the FM with Shamir'sSecret Sharing is deployed. HSM storage of this share, under certifiedFIPS 140-2 level 3 protections, ensures the entire master private key isnot vulnerable to key theft since it is not exposed outside of the HSM.A full key compromise entails key share compromises of multipledistributed HSM devices. Reconstruction of the full key and signingoccur on the HSM and thus is not vulnerable to memory-based attacks on awallet host.

At Ethereum transaction signing runtime (e.g., a TSS), key wrapping(e.g., via RSA keys) is used to protect confidentiality and integrity ofkey shares and transactions being transferred from other HSM devices tothe designated HSM for master key reconstruction and signing in the FM.Unwrapping RSA private keys and signing ECDSA keys do not leave the HSM.The SFTSP architecture may be deployed to both online and offline keysfor hot (e.g., networked) and cold (e.g., non-networked) storage (e.g.,runtime signing steps 1-3 describe online transaction signing with twokey shares in hot storage), and to mixed online and offline keys forair-gapped cold storage transaction signing (e.g., runtime signing steps11-16 describe offline transaction signing with three key shares in hotand cold storage).

The M-of-N authentication schema may be used to achieve key at-restprotection on HSM devices at multiple locations, while maintainingruntime key redundancy and availability for transaction signing.Together with HSM key replication, hardware redundancy andhigh-availability deployment, the HSM-based key storage infrastructuremay offer high scalability, load-balance and fail-over capabilities. TheM-of-N authentication schema may also be used for key share backup inlong-term offline storage locations for key recovery in case of disasterscenarios.

In one implementation, online transaction signing with key shares in hotstorage may be utilized. A transaction (tx) to sign may be obtained(e.g., requested by a user) by an online transaction signing runtime(e.g., a TSS) 2301. A second hot HSM 2309 may wrap (e.g., encrypt) hotkey share two H_priv_ss2 with the wrapping key H_RSA_pub of an RSA keypair generated by a first hot HSM 2305 and transfer the wrapped hot keyshare two to the first hot HSM (e.g., via the online transaction signingruntime). The first hot HSM may unwrap hot key share two using theunwrapping key H_RSA_priv, and merge hot key share two with hot keyshare one H_priv_ss1 into the hot master private key H_priv using amethod such as Shamir's Secret Sharing (e.g., via a SFTS module). Thetransaction may be signed using a BIP-32 derived child private key ofthe hot master private key (e.g., via the SFTS module).

In another implementation, offline transaction signing with key sharesin hot and cold storage may be utilized. A transaction (tx) to sign maybe obtained (e.g., requested by a user) by an online transaction signingruntime (e.g., a TSS) 2301 and provided to a first hot HSM 2305. Thefirst hot HSM may sign the transaction with the unwrapping keyH_RSA_priv of a hot RSA key pair generated by the first hot HSM, and maywrap (e.g., encrypt) online cold key share three C_priv_ss3 with thewrapping key C_RSA_pub of a cold RSA key pair generated by a first coldHSM 2325. The signed transaction and the wrapped online cold key sharethree may be transferred via an external storage device 2315 (e.g., aUSB drive) to the first cold HSM. The first cold HSM may unwrap onlinecold key share three using the unwrapping key C_RSA_priv of the cold RSApair. A second cold HSM 2329 may wrap (e.g., encrypt) offline cold keyshare two C_priv_ss2 with the wrapping key C_RSA_pub of the cold RSApair and transfer the wrapped offline cold key share two to the firstcold HSM (e.g., via an offline transaction signing runtime 2321 (e.g., aTSS)). The first cold HSM may unwrap offline cold key share two usingthe unwrapping key C_RSA_priv of the cold RSA pair, and merge onlinecold key share three, offline cold key share two, and offline cold keyshare one C_priv_ss1 into the cold master private key C_priv using amethod such as Shamir's Secret Sharing (e.g., via a SFTS module). Thefirst cold HSM may verify the signature of the transaction using thewrapping key H_RSA_pub of the hot RSA pair (e.g., to verify that thetransaction was provided by the first hot HSM), and the transaction maybe signed using a BIP-32 derived child private key of the cold masterprivate key (e.g., via the SFTS module).

FIGS. 24A-B show a datagraph diagram illustrating embodiments of a dataflow for the SFTSP. In FIGS. 24A-B, a client 2402 may send a transactionsigning (TS) request 2421 to a TSS server (e.g., an online transactionsigning runtime) 2406 to request that an EOA transaction be signed. Forexample, the client may be a desktop, a laptop, a tablet, a smartphone,and/or the like that is executing a client application. In oneimplementation, the TS request may include data such as a requestidentifier, user authentication data, a request type (e.g., sign messagehash), a wallet identifier, a transaction identifier, a transactionhash, a keychain path, and/or the like. In one embodiment, the clientmay provide the following example TS request, substantially in the formof a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /authrequest.php HTTP/1.1 Host: localhost Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <auth_request> <timestamp>2020-12-31 23:59:59</timestamp><user_accounts_details> <user_account_credentials><user_name>JohnDaDoeDoeDoooe@gmail.com</account_name><password>abc123</password> //OPTIONAL <cookie>cookieID</cookie>//OPTIONAL <digital_cert_link>www.mydigitalcertificate.com/JohnDoeDaDoeDoe@gmail.com/mycertifcate.dc</digital_cert_link> //OPTIONAL<digital_certificate>_DATA_</digital_certificate></user_account_credentials> </user_accounts_details> <TS_request><request_identifier>ID_request_31</request_identifier><request_type>SIGN_TRANSACTION</request_type><wallet_identifier>ID_Wallet31</wallet_identifier><transaction_identifier>ID_transaction_31</transaction_identifier><transaction_hash>256-bit hash value to be signed</transaction_hash><keychain_path>m/0/0/1/0</keychain_path> </TS_request> </auth_request>

A transaction server transaction signing (TSTS) component 2425 mayutilize parameters provided in the TS request to facilitate transactionsigning. See FIG. 25 for additional details regarding the TSTScomponent.

The TSS server may send a public key request message 2429 to a first hotHSM 2410 to request a RSA public key from the first hot HSM. In oneimplementation, the public key request message may be sent via a HSMAccess Provider and may include data such as a request identifier, atransaction identifier, and/or the like. In one embodiment, the TSSserver may provide the following example public key request message,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /public_key_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <public_key_request_message><request_identifier>ID_request_32</request_identifier><transaction_identifier>ID_transaction_31</transaction_identifier></public_key_request_message>

The first hot HSM may provide a RSA public key to the TSS server via apublic key response message 2433. In one implementation, the public keyresponse message may include data such as a response identifier, atransaction identifier, a RSA public key, and/or the like. In oneembodiment, the first hot HSM may provide the following example publickey response message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /public_key_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <public_key_response_message><response_identifier>ID_response_32</response_identifier><transaction_identifier>ID_transaction_31</transaction_identifier><RSA_public_key>RSA public key provided by the 1^(st) hotHSM</RSA_public_key> </public_key_response_message>

The TSS server may send a master key share request message 2437 to asecond hot HSM 2414 to request an encrypted master key share (e.g., fora specified wallet) from the second hot HSM. In one implementation, themaster key share request message may include data such as a requestidentifier, a transaction identifier, a wallet identifier, a RSA publickey, and/or the like. In one embodiment, the TSS server may provide thefollowing example master key share request message, substantially in theform of a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /master_key_share_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_share_request_message><request_identifier>ID_request_33</request_identifier><transaction_identifier>ID_transaction_31</transaction_identifier><wallet_identifier>ID_Wallet31</wallet_identifier> <RSA_public_key>RSApublic key provided by the 1^(st) hot HSM</RSA_public_key></master_key_share_request_message>

The second hot HSM may provide the encrypted master key share to the TSSserver via a master key share response message 2441. In oneimplementation, the master key share response message may include datasuch as a response identifier, a transaction identifier, a walletidentifier, an encrypted master key share, and/or the like. In oneembodiment, the second hot HSM may provide the following example masterkey share response message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /master_key_share_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_share_response_message><response_identifier>ID_response_33</response_identifier><transaction_identifier>ID_transaction_31</transaction_identifier><wallet_identifier>ID_Wallet31</wallet_identifier><master_key_share>encrypted master key share provided by the 2^(nd) hotHSM</master_key_share> </master_key_share_response_message>

The TSS server may send a TS request message 2445 to the first hot HSMto request that the first hot HSM sign the transaction. In oneimplementation, the TS request message may be sent via a HSM AccessProvider and may include data such as a request identifier, a requesttype (e.g., sign message hash), a wallet identifier, a transactionidentifier, a transaction hash, a keychain path, an encrypted master keyshare, and/or the like. For example, the TSS server may provide thefollowing example TS request message, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /TS_request_message.php HTTP/1.1 Host: localhost Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_request_message><request_identifier>ID_request_34</request_identifier><request_type>SIGN_TRANSACTION</request_type><wallet_identifier>ID_Wallet31</wallet_identifier><transaction_identifier>ID_transaction_31</transaction_identifier><transaction_hash>256-bit hash value to be signed</transaction_hash><keychain_path>m/0/0/1/0</keychain_path> <master_key_share>encryptedmaster key share provided by the 2^(nd) hot HSM</master_key_share></TS_request_message>

The first hot HSM may make a SFTS API call 2449 to a SFTS module 2418 torequest that the SFTS module sign the transaction. In oneimplementation, the SFTS API call may include data such as a requesttype (e.g., sign message hash), a wallet identifier, a transactionidentifier, a transaction hash, a keychain path, an encrypted master keyshare, and/or the like.

Data provided in the SFTS API call may be used by a secure firmwaretransaction signing (SFTS) component 2453 to determine a master privatekey from master key shares and to sign the transaction (e.g., togenerate an ECDSA signature in DER format). See FIG. 26 for additionaldetails regarding the SFTS component.

The SFTS module may send SFTS response data 2457 to the first hot HSM inresponse to the SFTS API call. In one implementation, the SFTS responsedata may include an ECDSA signature in DER format.

The first hot HSM may send a TS response message 2461 to the TSS server(e.g., via a HSM Access Provider). In one implementation, the TSresponse message may include data such as a response identifier, atransaction identifier, a transaction signature, and/or the like. Forexample, the first hot HSM may provide the following example TS responsemessage, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /TS_response_message.php HTTP/1.1 Host: localhost Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_response_message><response_identifier>ID_response_34</response_identifier><transaction_identifier>ID_transaction_31</transaction_identifier><transaction_signature>ECDSA signature in DERformat</transaction_signature> </TS_response_message>

The TSS server may send a TS response 2465 to the client. In oneimplementation, the TS response may include data such as a responseidentifier, a transaction identifier, a transaction signature, and/orthe like. For example, the TSS server may provide the following exampleTS response, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /TS_response.php HTTP/1.1 Host: www.server.com Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_response><response_identifier>ID_response_31</response_identifier><transaction_identifier>ID_transaction_31</transaction_identifier><transaction_signature>ECDSA signature in DERformat</transaction_signature> </TS_response>

FIG. 25 shows a logic flow diagram illustrating embodiments of atransaction server transaction signing (TSTS) component for the SFTSP.In FIG. 25, a transaction signing request may be obtained at 2502. Forexample, the transaction signing request may be obtained as a result ofa user utilizing a UI of an online transaction signing runtime CLIprogram to initiate transaction signing (e.g., a fund transfer EOAtransaction on Ethereum blockchain) using a master key associated with ahierarchical deterministic wallet.

An RSA public key may be requested from a first hot HSM at 2506. In oneimplementation, a public key request message may be sent to the firsthot HSM to request the RSA public key.

A determination may be made at 2508 whether the obtained RSA public keyis valid. For example, the fund transfer program may be configured towork with a specified set of HSMs, and the obtained RSA public key mayhave to be associated with one of the specified HSMs to be valid.

If the obtained RSA public key is not valid, an error message may begenerated at 2518. For example, the error message may specify the errorthat occurred (e.g., RSA public key is not valid). A warning message maybe provided to the user and/or an action may be triggered at 2520. Inone implementation, a warning message based on the generated errormessage may be provided to the user to inform the user regarding theerror. In another implementation, an action may be triggered based on aspecified condition (e.g., invalid RSA public key obtained three times).For example, the triggered action may be to erase data associated withthe wallet. In another example, the triggered action may be toinvalidate the master key and to generate a new master key.

If the obtained RSA public key is valid, the RSA public key may beprovided to a second hot HSM at 2510. For example, the RSA public keymay be utilized by the second hot HSM to encrypt a second master privatekey share stored by the second hot HSM such that the corresponding RSAprivate key, available to the first hot HSM, may be used to decrypt thesecond master private key share. In one implementation, the RSA publickey may be forwarded to the second hot HSM via a master key sharerequest message.

An encrypted second master private key share (e.g., for the specifiedwallet) may be requested from the second hot HSM at 2512. In oneimplementation, a master key share request message may be sent to thesecond hot HSM to request the second master private key share encryptedwith the RSA public key.

A determination may be made at 2514 whether the request for theencrypted second master private key share is authorized. In oneimplementation, one or more operators (e.g., based on M-of-Nauthentication) may have to approve (e.g., via an authentication entrydevice associated with the second hot HSM) the request to export theencrypted second master private key share from the second hot HSM forthe request to be authorized.

If the request for the encrypted second master private key share is notauthorized, an error message may be generated at 2518. For example, theerror message may specify the error that occurred (e.g., request toexport the encrypted second master private key share from the second hotHSM is not authorized). A warning message may be provided to the userand/or an action may be triggered at 2520. In one implementation, awarning message based on the generated error message may be provided tothe user to inform the user regarding the error. In anotherimplementation, an action may be triggered based on a specifiedcondition (e.g., unauthorized request occurred three times). Forexample, the triggered action may be to erase data associated with thewallet. In another example, the triggered action may be to invalidatethe master key and to generate a new master key.

If the request for the encrypted second master private key share isauthorized, transaction signing may be requested from the first hot HSMat 2522. In one implementation, a transaction signing request messagemay be sent to the first hot HSM to request transaction signing.

A transaction signing response may be provided to the client at 2526. Inone implementation, a transaction signing response may be sent to theclient to inform the user whether the transaction signing was completedsuccessfully (e.g., via a UI of the online transaction signing runtime).

FIG. 26 shows a logic flow diagram illustrating embodiments of a securefirmware transaction signing (SFTS) component for the SFTSP. In FIG. 26,a public key request from a TSS may be obtained at 2603. For example,the public key request may be obtained as a result of the TSSfacilitating transaction signing.

A RSA key pair may be generated at 2607. In one embodiment, a RSA keypair (e.g., a RSA public key and a corresponding RSA private key) may bepredefined (e.g., for a HSM). In one implementation, the RSA public keymay be determined using a PKCS#11 function (e.g., C_FindObjectsInit( . .. )). In another implementation, the RSA public key may be determinedvia an internal call on a HSM environment setting configured externallyat HSM deployment time. In an alternative implementation, the RSA publickey may be determined via a MySQL database command (e.g., retrieved froma MySQL database in tamper-proof storage). In another embodiment, a RSAkey pair may be generated dynamically (e.g., each time transactionsigning is executed). In one implementation, a RSA public key may begenerated using a PKCS#11 function (e.g., C_CreateObject( . . . )).

The RSA public key may be provided to the TSS at 2611. In oneimplementation, the RSA public key may be provided to the TSS via apublic key response message.

A SFTS API call may be obtained at 2615. For example, the SFTS API callmay be obtained as a result of a call from a first hot HSM associatedwith the SFTS component. It is to be understood that although the SFTScomponent is described with regard to an API method to sign atransaction (e.g., signMessageHash), in some embodiment, a variety ofAPI methods may be available. In one embodiment, the following APImethods may be available to the first hot HSM and/or to a TSS:

-   -   signMessageHash—this method receives a message hash, a keychain        path and a handle to the transient object containing a second        master private key share (e.g., encrypted), and returns an ECDSA        signature value. Seed reconstruction from shares and key        derivation steps are implemented by the SFTS component.        Temporary keys generated for signing are wiped out of the device        once the signing process is complete.        -   Input:            -   256-bit hash value to be signed            -   keychain path to be used for Bip32 key derivation            -   handle to the transient object containing a second                master private key share (e.g., encrypted)        -   Output:            -   ECDSA signature in DER format

An encrypted second master private key share utilized to recover amaster private key may be determined at 2619. In one implementation, theencrypted second master private key share may be provided as an inputparameter in the SFTS API call.

A determination may be made at 2623 whether the encrypted second masterprivate key share is decryptable. In one implementation, thisdetermination may be made by checking whether decrypting the encryptedsecond master private key share using the RSA private key results in avalid object.

If the encrypted second master private key share is not decryptable, anerror message may be generated at 2627. For example, the error messagemay specify the error that occurred (e.g., second master private keyshare is not decryptable). A warning message may be provided to a userand/or an action may be triggered at 2631. In one implementation, awarning message based on the generated error message may be provided tothe user (e.g., via the TSS) to inform the user regarding the error. Inanother implementation, an action may be triggered based on a specifiedcondition (e.g., non-decryptable second master private key shareobtained three times). For example, the triggered action may be to erasedata associated with an associated wallet. In another example, thetriggered action may be to invalidate the master key associated with thesecond master private key share and to generate a new master key.

If the encrypted second master private key share is decryptable, theencrypted second master private key share may be decrypted using the RSAprivate key at 2635. In one implementation, the RSA private key may bedetermined using a PKCS#11 function (e.g., C_FindObjectsInit( . . . )).In another implementation, the RSA private key may be determined via aninternal call on a HSM environment setting configured externally at HSMdeployment time. In an alternative implementation, the RSA private keymay be determined via a MySQL database command (e.g., retrieved from aMySQL database in tamper-proof storage). In one implementation, theencrypted second master private key share may be decrypted using aPKCS#11 function (e.g., C_Decrypt( . . . )).

A first master private key share may be retrieved at 2639. In oneimplementation, the first master private key share may be determinedusing a PKCS#11 function (e.g., C_FindObjectsInit( . . . )). In anotherimplementation, the first master private key share may be determined viaan internal call on a HSM environment setting configured externally atHSM deployment time. In an alternative implementation, the first masterprivate key share may be determined via a MySQL database command (e.g.,retrieved from a MySQL database in tamper-proof storage).

A master private key may be determined from master private key shares(e.g., from the first master private key share and the second masterprivate key share) at 2643. In one embodiment, a method such as Shamir'sSecret Sharing may be utilized to recover the master private key fromthe master private key shares. See FIG. 14 for additional detailsregarding utilizing Shamir's Secret Sharing.

Transaction data may be determined at 2647. In one implementation, thetransaction data may be provided in the SFTS API call and may include awallet identifier, a transaction identifier, a transaction hash, akeychain path, and/or the like.

A signing private key for the specified keychain path may be generatedusing the determined master private key at 2651. In one implementation,the signing private key may be generated in accordance with adeterministic key derivation procedure as described in Bip32. Thetransaction may be signed at 2655. In one implementation, the generatedsigning private key may be used to sign the transaction hash inaccordance with the hashing algorithm utilized by the Ethereum protocol(e.g., KECCAK256(RLP(message))). For example, the transaction may besigned using a Keccak hash function of a recursive length prefix (RLP)of the message.

Temporary private key data may be wiped from memory at 2659. In oneimplementation, the second master private key share obtained from thesecond hot HSM, the determined master private key, and/or the generatedsigning private key may be wiped from memory of the first hot HSMassociated with the SFTS component. The signed transaction may bereturned at 2663. In one implementation, the ECDSA signature in DERformat may be returned.

FIGS. 27A-C show a datagraph diagram illustrating embodiments of a dataflow for the SFTSP. In FIGS. 27A-C, a user of a client 2702 may send atransaction signing (TS) request 2721 to an online TSS server (e.g., anonline transaction signing runtime) 2704 to request that an EOAtransaction be signed. For example, the client may be a desktop, alaptop, a tablet, a smartphone, and/or the like that is executing aclient application. In one implementation, the TS request may includedata such as a request identifier, user authentication data, a requesttype (e.g., sign message hash), a wallet identifier, a transactionidentifier, a transaction hash, a keychain path, and/or the like. In oneembodiment, the client may provide the following example TS request,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /authrequest.php HTTP/1.1 Host: localhost Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <auth_request> <timestamp>2020-12-31 23:59:59</timestamp><user_accounts_details> <user_account_credentials><user_name>JohnDaDoeDoeDoooe@gmail.com</account_name><password>abc123</password> //OPTIONAL <cookie>cookieID</cookie>//OPTIONAL <digital_cert_link>www.mydigitalcertificate.com/JohnDoeDaDoeDoe@gmail.com/mycertifcate.dc</digital_cert_link> //OPTIONAL<digital_certificate>_DATA_</digital_certificate></user_account_credentials> </user_accounts_details> <TS_request><request_identifier>ID_request_41</request_identifier><request_type>SIGN_TRANSACTION</request_type><wallet_identifier>ID_Wallet41</wallet_identifier><transaction_identifier>ID_transaction_41</transaction_identifier><transaction_hash>256-bit hash value to be signed</transaction_hash><keychain_path>m/0/0/1/0</keychain_path> </TS_request> </auth_request>

An online transaction server transaction signing (NTSTS) component 2725may utilize parameters provided in the TS request to facilitatetransaction signing. See FIG. 28 for additional details regarding theNTSTS component.

The online TSS server may send an online TS request message 2729 to ahot HSM 2706 to request transferable data from the hot HSM to facilitatetransaction signing. In one implementation, the online TS requestmessage may be sent via a HSM Access Provider and may include data suchas a request identifier, a request type (e.g., get transferable data), awallet identifier, a transaction identifier, transaction data, and/orthe like. For example, the online TSS server may provide the followingexample online TS request message, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /online_TS_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <online_TS_request_message><request_identifier>ID_request_42</request_identifier><request_type>GET_TRANSFERABLE_DATA</request_type><wallet_identifier>ID_Wallet41</wallet_identifier><transaction_identifier>ID_transaction_41</transaction_identifier><transaction_data>transaction data to be signed</transaction_data></online_TS_request_message>

The hot HSM may make a hot SFTS API call 2733 to a hot SFTS module 2710to request that the hot SFTS module provide the transferable data. Inone implementation, the hot SFTS API call may include data such as arequest type (e.g., get transferable data), a wallet identifier, atransaction identifier, transaction data, and/or the like.

Data provided in the hot SFTS API call may be used by a hot securefirmware transaction signing (HSFTS) component 2737 to provide thetransferable data. For example, the transferable data may include anencrypted third master private key share (e.g., encrypted with a publickey encryption key of a first cold HSM 2714) and signed transaction data(e.g., signed with a RSA private key of the hot HSM). See FIG. 29 foradditional details regarding the HSFTS component.

The hot SFTS module may send hot SFTS response data 2741 to the hot HSMin response to the hot SFTS API call. In one implementation, the hotSFTS response data may include the transferable data.

The hot HSM may send an online TS response message 2745 to the onlineTSS server (e.g., via a HSM Access Provider). In one implementation, theonline TS response message may include data such as a responseidentifier, a transaction identifier, transferable data, and/or thelike. For example, the hot HSM may provide the following example onlineTS response message, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /online_TS_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <online_TS_response_message><response_identifier>ID_response_42</response_identifier><transaction_identifier>ID_transaction_41</transaction_identifier><transferable_data> <master_key_share>encrypted master key shareprovided by the hot HSM</master_key_share> <transaction_data>hot HSMsigned transaction data</transaction_data> </transferable_data></online_TS_response_message>

The online TSS server may copy the transferable data 2749 and/or otherdata to an external storage device 2708. In various implementations, theexternal storage device may be a USB drive (e.g., a flash drive, a harddrive), an SD card, an optical disk, and/or the like.

An offline TSS server 2712 may copy the transferable data 2753 and/orother data from the external storage device. In one implementation, theuser may move the external storage device from the online TSS server tothe offline TSS server, and may utilize the offline TSS server (e.g., anoffline transaction signing runtime) to request that the transaction besigned using the transferable data (e.g., resulting in the copying).

An offline transaction server transaction signing (FTSTS) component 2757may utilize the transferable data to facilitate transaction signing. SeeFIG. 30 for additional details regarding the FTSTS component.

In some embodiments, the offline TSS server may send a master key sharerequest message 2761 to a second cold HSM 2716 to request an encryptedmaster key share (e.g., for a specified wallet) from the second coldHSM. In one implementation, the master key share request message mayinclude data such as a request identifier, a transaction identifier, awallet identifier, and/or the like. For example, the offline TSS servermay provide the following example master key share request message,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /master_key_share_request_message.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_share_request_message><request_identifier>ID_request_43</request_identifier><transaction_identifier>ID_transaction_41</transaction_identifier><wallet_identifier>ID_Wallet41</wallet_identifier></master_key_share_request_message>

In some embodiments, the second cold HSM may provide the encryptedmaster private key share (e.g., second master private key shareencrypted with a public key encryption key of the first cold HSM) to theoffline TSS server via a master key response message 2765. In oneimplementation, the master key share response message may include datasuch as a response identifier, a transaction identifier, a walletidentifier, an encrypted master key share, and/or the like. In oneembodiment, the second cold HSM may provide the following example masterkey share response message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /master_key_share_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <master_key_share_response_message><response_identifier>ID_response_43</response_identifier><transaction_identifier>ID_transaction_41</transaction_identifier><wallet_identifier>ID_Wallet41</wallet_identifier><master_key_share>encrypted master key share provided by the 2^(nd) coldHSM</master_key_share> </master_key_share_response_message>

The offline TSS server may send an offline TS request message 2769 tothe first cold HSM 2714 to request that the first cold HSM sign thetransaction. In one implementation, the offline TS request message maybe sent via a HSM Access Provider and may include data such as a requestidentifier, a request type (e.g., sign message hash), a walletidentifier, a transaction identifier, a transaction hash, a keychainpath, transferable data, an encrypted master key share, and/or the like.For example, the offline TSS server may provide the following exampleoffline TS request message, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /offline_TS_request_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <offline_TS_request_message><request_identifier>ID_request_44</request_identifier><request_type>SIGN_TRANSACTION</request_type><wallet_identifier>ID_Wallet41</wallet_identifier><transaction_identifier>ID_transaction_41</transaction_identifier><transaction_hash>256-bit hash value to be signed</transaction_hash><keychain_path>m/0/0/1/0</keychain_path> <transferable_data><master_key_share>encrypted master key share provided by the hotHSM</master_key_share> <transaction_data>hot HSM signed transactiondata</transaction_data> </transferable_data> <master_key_share>encryptedmaster key share provided by the 2^(nd) cold HSM</master_key_share></offline_TS_request_message>

The first cold HSM may make a cold SFTS API call 2773 to a cold SFTSmodule 2718 to request that the cold SFTS module sign the transaction.In one implementation, the cold SFTS API call may include data such as arequest identifier, a request type (e.g., sign message hash), a walletidentifier, a transaction identifier, a transaction hash, a keychainpath, transferable data, an encrypted master key share, and/or the like.

Data provided in the cold SFTS API call may be used by a cold securefirmware transaction signing (CSFTS) component 2777 to determine amaster private key from master key shares and to sign the transaction(e.g., to generate an ECDSA signature in DER format). See FIG. 31 foradditional details regarding the CSFTS component.

The cold SFTS module may send cold SFTS response data 2781 to the firstcold HSM in response to the cold SFTS API call. In one implementation,the SFTS response data may include an ECDSA signature in DER format.

The first cold HSM may send an offline TS response message 2785 to theoffline TSS server (e.g., via a HSM Access Provider). In oneimplementation, the offline TS response message may include data such asa response identifier, a transaction identifier, a transactionsignature, and/or the like. For example, the first cold HSM may providethe following example offline TS response message, substantially in theform of a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /offline_TS_response_message.php HTTP/1.1 Host: localhostContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <offline_TS_response_message><response_identifier>ID_response_44</response_identifier><transaction_identifier>ID_transaction_41</transaction_identifier><transaction_signature>ECDSA signature in DERformat</transaction_signature> </offline_TS_response_message>

The offline TSS server may copy the signed transaction (e.g., thetransaction signature) 2789 and/or other data to the external storagedevice.

The online TSS server may copy the signed transaction (e.g., thetransaction signature) 2793 and/or other data from the external storagedevice. In one implementation, the user may move the external storagedevice from the offline TSS server to the online TSS server, and mayutilize the online TSS server to finalize transaction processing usingthe signed transaction (e.g., resulting in the copying).

The online TSS server may send a TS response 2797 to the client. In oneimplementation, the TS response may include data such as a responseidentifier, a transaction identifier, a transaction signature, and/orthe like. For example, the online TSS server may provide the followingexample TS response, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /TS_response.php HTTP/1.1 Host: www.server.com Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <TS_response><response_identifier>ID_response_41</response_identifier><transaction_identifier>ID_transaction_41</transaction_identifier><transaction_signature>ECDSA signature in DERformat</transaction_signature> </TS_response>

FIG. 28 shows a logic flow diagram illustrating embodiments of an onlinetransaction server transaction signing (NTSTS) component for the SFTSP.In FIG. 28, a transaction signing request may be obtained at 2801. Forexample, the transaction signing request may be obtained as a result ofa user utilizing a UI of an online transaction signing runtime toinitiate transaction signing (e.g., a fund transfer EOA transaction onEthereum blockchain) using a master key associated with a hierarchicaldeterministic wallet.

Transferable data may be requested from a hot HSM at 2805. For example,the transferable data may include an encrypted third master private keyshare and signed transaction data. In one implementation, an online TSrequest message may be sent to the hot HSM to request the transferabledata.

A determination may be made at 2809 whether the request for thetransferable data is authorized. In one implementation, one or moreoperators (e.g., based on M-of-N authentication) may have to approve(e.g., via an authentication entry device associated with the hot HSM)the request to provide the transferable data for the request to beauthorized.

If the request for the transferable data is not authorized, an errormessage may be generated at 2813. For example, the error message mayspecify the error that occurred (e.g., request to provide thetransferable data is not authorized). A warning message may be providedto the user and/or an action may be triggered at 2817. In oneimplementation, a warning message based on the generated error messagemay be provided to the user to inform the user regarding the error. Inanother implementation, an action may be triggered based on a specifiedcondition (e.g., unauthorized request occurred three times). Forexample, the triggered action may be to erase data associated with thewallet. In another example, the triggered action may be to invalidatethe master key and to generate a new master key.

If the request for the transferable data is authorized, transaction datasigned by the hot HSM may be obtained at 2821 and the encrypted thirdmaster private key share may be obtained at 2825 as parts of thetransferable data. The obtained transferable data and/or other datautilized to process the transaction may be copied to an external storagedevice at 2829.

A determination may be made at 2833 whether the signed transaction isavailable. In one implementation, the user may utilize the UI of theonline transaction signing runtime to indicate that the external storagedevice (e.g., or another USB storage device) containing the signedtransaction has been inserted. In another implementation, a notificationthat the external storage device (e.g., or another USB storage device)has been inserted may be obtained from the operating system and theexternal storage device may be checked to determine whether the externalstorage device contains the signed transaction. If the signedtransaction is not available, the SFTSP may wait until the signedtransaction is available at 2837.

If the signed transaction is available, the signed transaction may becopied from the external storage at 2841. For example, the signedtransaction may include an ECDSA signature in DER format.

A transaction signing response may be provided to the client at 2845. Inone implementation, a transaction signing response may be sent to theclient to inform the user whether the transaction signing was completedsuccessfully (e.g., via a UI of the online transaction signing runtime).

FIG. 29 shows a logic flow diagram illustrating embodiments of a hotsecure firmware transaction signing (HSFTS) component for the SFTSP. InFIG. 29, a hot SFTS API call may be obtained at 2901. For example, thehot SFTS API call may be obtained as a result of a call from a hot HSMassociated with the HSFTS component. It is to be understood thatalthough the HSFTS component is described with regard to an API methodto provide transferable data, in some embodiment, a variety of APImethods may be available.

Transaction data may be determined at 2905. In one implementation, thetransaction data may be provided in the hot SFTS API call and mayinclude a wallet identifier, a transaction identifier, a transactionhash, a keychain path, and/or the like.

A RSA private key for the hot HSM may be retrieved at 2909. In oneembodiment, a RSA key pair (e.g., a RSA public key and a correspondingRSA private key) may be predefined (e.g., for the hot HSM). In oneimplementation, the hot HSM RSA private key may be determined using aPKCS#11 function (e.g., C_FindObjectsInit( . . . )). In anotherimplementation, the hot HSM RSA private key may be determined via aninternal call on a HSM environment setting configured externally at HSMdeployment time. In an alternative implementation, the hot HSM RSAprivate key may be determined via a MySQL database command (e.g.,retrieved from a MySQL database in tamper-proof storage). In anotherembodiment, a RSA key pair may be generated dynamically (e.g., each timetransaction signing is executed). In one implementation, the hot HSM RSAprivate key may be generated using a PKCS#11 function (e.g.,C_CreateObject( . . . )).

The transaction data may be signed with the hot HSM RSA private key at2913. In one implementation, the transaction data may be signed using aPKCS#11 function (e.g., C_Sign( . . . )).

A third master private key share may be retrieved at 2917. In oneimplementation, the third master private key share may be determinedusing a PKCS#11 function (e.g., C_FindObjectsInit( . . . )). In anotherimplementation, the third master private key share may be determined viaan internal call on a HSM environment setting configured externally atHSM deployment time. In an alternative implementation, the third masterprivate key share may be determined via a MySQL database command (e.g.,retrieved from a MySQL database in tamper-proof storage).

A public key encryption key of a paired cold HSM may be retrieved at2921. For example, the public key encryption key may be an RSA publickey that corresponds to the RSA private key stored in tamper-proofstorage of the paired cold HSM (e.g., first cold HSM 2714). In oneimplementation, the public key encryption key may be determined using aPKCS#11 function (e.g., C_FindObjectsInit( . . . )). In anotherimplementation, the public key encryption key may be determined via aninternal call on a HSM environment setting configured externally at HSMdeployment time. In an alternative implementation, the public keyencryption key may be determined via a MySQL database command (e.g.,retrieved from a MySQL database in tamper-proof storage). In anotheralternative implementation, the public key encryption key may begenerated dynamically (e.g., each time transaction signing is executed)by the paired cold HSM and obtained using public key request and publickey response messages (e.g., via an external storage device).

The third master private key share may be encrypted with the public keyencryption key of the paired cold HSM at 2925. In one implementation,the third master private key share may be encrypted using a PKCS#11function (e.g., C_Encrypt( . . . )).

The signed transaction data and/or the encrypted third master privatekey share may be returned at 2929. In one implementation, thetransferable data (e.g., the signed transaction data and/or theencrypted third master private key share) may be an output of the hotSFTS API call.

FIG. 30 shows a logic flow diagram illustrating embodiments of anoffline transaction server transaction signing (FTSTS) component for theSFTSP. In FIG. 30, a transaction signing request may be obtained at3001. For example, the transaction signing request may be obtained as aresult of a user utilizing a UI of an offline transaction signingruntime to request that a transaction (e.g., a fund transfer EOAtransaction on Ethereum blockchain) be signed using transferable datafrom an external storage device (e.g., a USB drive inserted by theuser).

The transferable data associated with the transaction may be copied fromthe external storage device at 3005. For example, the transferable datamay include an encrypted third master private key share and transactiondata signed by a hot HSM.

An encrypted second master private key share (e.g., for a walletassociated with the transaction) may be requested from a second cold HSMat 3009. In one implementation, a master key share request message maybe sent to the second cold HSM to request the second master private keyshare encrypted with an RSA public key that corresponds to the RSAprivate key stored in tamper-proof storage of a first cold HSM. It is tobe understood that, depending on the number of key shares used toreconstruct a full master private key, any number (e.g., none, one,multiple) of second cold HSMs may be utilized in this manner to obtainsecond master private key shares (e.g., if five key shares are used,three key shares from three second cold HSMs may be utilized in additionto a key share from the hot HSM and a key share from a first cold HSM).

A determination may be made at 3013 whether the request for theencrypted second master private key share is authorized. In oneimplementation, one or more operators (e.g., based on M-of-Nauthentication) may have to approve (e.g., via an authentication entrydevice associated with the second cold HSM) the request to export theencrypted second master private key share from the second cold HSM forthe request to be authorized.

If the request for the encrypted second master private key share is notauthorized, an error message may be generated at 3017. For example, theerror message may specify the error that occurred (e.g., request toexport the encrypted second master private key share from the secondcold HSM is not authorized). A warning message may be provided to theuser and/or an action may be triggered at 3021. In one implementation, awarning message based on the generated error message may be provided tothe user to inform the user regarding the error. In anotherimplementation, an action may be triggered based on a specifiedcondition (e.g., unauthorized request occurred three times). Forexample, the triggered action may be to erase data associated with thewallet. In another example, the triggered action may be to invalidatethe master key and to generate a new master key.

If the request for the encrypted second master private key share isauthorized, transaction signing may be requested from the first cold HSMat 3025. In one implementation, a transaction signing request messagemay be sent to the first cold HSM to request transaction signing.

The signed transaction (e.g., the transaction signature) may be copiedto an external storage device at 3029. In one implementation, the signedtransaction may be utilized by the NTSTS component to provide atransaction signing response.

FIG. 31 shows a logic flow diagram illustrating embodiments of a coldsecure firmware transaction signing (CSFTS) component for the SFTSP. InFIG. 31, a cold SFTS API call may be obtained at 3101. For example, thecold SFTS API call may be obtained as a result of a call from a firstcold HSM associated with the CSFTS component. It is to be understoodthat although the CSFTS component is described with regard to an APImethod to sign a transaction (e.g., signMessageHash), in someembodiment, a variety of API methods may be available. In oneembodiment, the following API methods may be available to the first coldHSM and/or to an offline TSS:

-   -   signMessageHash—this method receives a message hash, a keychain        path and a handle to the transient object containing a second        master private key share (e.g., encrypted), and returns an ECDSA        signature value. Seed reconstruction from shares and key        derivation steps are implemented by the CSFTS component.        Temporary keys generated for signing are wiped out of the device        once the signing process is complete.        -   Input:            -   256-bit hash value to be signed            -   keychain path to be used for Bip32 key derivation            -   handle to the transient object containing a second                master private key share (e.g., encrypted)        -   Output:            -   ECDSA signature in DER format

Encrypted master private key shares utilized to recover a master privatekey may be determined at 3105. For example, the encrypted master privatekey shares may include an encrypted second master private key share(e.g., from a second cold HSM) and an encrypted third master private keyshare (e.g., from a paired hot HSM). In one implementation, theencrypted master private key shares may be provided as input parametersin the cold SFTS API call.

A determination may be made at 3109 whether the encrypted master privatekey shares are decryptable. In one implementation, this determinationmay be made by checking whether decrypting the encrypted master privatekey shares using a private key decryption key stored in tamper-proofstorage of the first cold HSM results in valid objects.

If the encrypted master private key shares are not decryptable, an errormessage may be generated at 3113. For example, the error message mayspecify the error that occurred (e.g., master private key shares are notdecryptable). A warning message may be provided to a user and/or anaction may be triggered at 3117. In one implementation, a warningmessage based on the generated error message may be provided to the user(e.g., via the offline TSS) to inform the user regarding the error. Inanother implementation, an action may be triggered based on a specifiedcondition (e.g., non-decryptable master private key shares obtainedthree times). For example, the triggered action may be to erase dataassociated with an associated wallet. In another example, the triggeredaction may be to invalidate the master key associated with the masterprivate key shares and to generate a new master key.

If the encrypted master private key shares are decryptable, theencrypted master private key shares may be decrypted using the privatekey decryption key at 3121. For example, the private key decryption keymay be an RSA private key that corresponds to the RSA public keyprovided to other HSMs. In one implementation, the RSA private key maybe determined using a PKCS#11 function (e.g., C_FindObjectsInit( . . .)). In another implementation, the RSA private key may be determined viaan internal call on a HSM environment setting configured externally atHSM deployment time. In an alternative implementation, the RSA privatekey may be determined via a MySQL database command (e.g., retrieved froma MySQL database in tamper-proof storage). In another alternativeimplementation, the RSA private key may be generated dynamically (e.g.,each time transaction signing is executed) and provided to other HSMsusing public key request and public key response messages. In oneimplementation, the encrypted master private key shares may be decryptedusing a PKCS#11 function (e.g., C_Decrypt( . . . )).

A first master private key share may be retrieved at 3125. In oneimplementation, the first master private key share may be determinedusing a PKCS#11 function (e.g., C_FindObjectsInit( . . . )). In anotherimplementation, the first master private key share may be determined viaan internal call on a HSM environment setting configured externally atHSM deployment time. In an alternative implementation, the first masterprivate key share may be determined via a MySQL database command (e.g.,retrieved from a MySQL database in tamper-proof storage).

A master private key may be determined from master private key shares(e.g., from the first master private key share, the second masterprivate key share and the third master private key share) at 3129. Inone embodiment, a method such as Shamir's Secret Sharing may be utilizedto recover the master private key from the master private key shares.See FIG. 14 for additional details regarding utilizing Shamir's SecretSharing.

Transaction data may be determined at 3133. In one implementation, thetransaction data may be provided in the cold SFTS API call and mayinclude a wallet identifier, a transaction identifier, a transactionhash, a keychain path, and/or the like.

A determination may be made at 3137 whether the transaction data isvalid. In one embodiment, this determination may be made by checkingwhether the transaction data has a valid signature from the paired hotHSM. For example, checking the signature facilitates verifying that thetransaction data was provided by the paired hot HSM. In oneimplementation, the signature may be verified using a PKCS#11 function(e.g., C_Verify ( . . . )).

If the signature is invalid, an error message may be generated at 3113.For example, the error message may specify the error that occurred(e.g., transaction data signature is invalid). A warning message may beprovided to a user and/or an action may be triggered at 3117. In oneimplementation, a warning message based on the generated error messagemay be provided to the user (e.g., via the offline TSS) to inform theuser regarding the error. In another implementation, an action may betriggered based on a specified condition (e.g., transaction data withinvalid signature obtained three times). For example, the triggeredaction may be to erase data associated with an associated wallet. Inanother example, the triggered action may be to invalidate the masterkey associated with the master private key shares and to generate a newmaster key.

If the signature is valid, a signing private key for the specifiedkeychain path may be generated using the determined master private keyat 3141. In one implementation, the signing private key may be generatedin accordance with a deterministic key derivation procedure as describedin Bip32. The transaction may be signed at 3145. In one implementation,the generated signing private key may be used to sign the transactionhash in accordance with the hashing algorithm utilized by the Ethereumprotocol (e.g., KECCAK256(RLP(message))). For example, the transactionmay be signed using a Keccak hash function of a recursive length prefix(RLP) of the message.

Temporary private key data may be wiped from memory at 3149. In oneimplementation, the second master private key share obtained from thesecond cold HSM, the third master private key share obtained from thepaired hot HSM, the determined master private key, and/or the generatedsigning private key may be wiped from memory of the first cold HSMassociated with the CSFTS component. The signed transaction may bereturned at 3153. In one implementation, the ECDSA signature in DERformat may be returned.

SFTSP Controller

FIG. 32 shows a block diagram illustrating embodiments of a SFTSPcontroller. In this embodiment, the SFTSP controller 3201 may serve toaggregate, process, store, search, serve, identify, instruct, generate,match, and/or facilitate interactions with a computer throughinformation technology technologies, and/or other related data.

Users, which may be people and/or other systems, may engage informationtechnology systems (e.g., computers) to facilitate informationprocessing. In turn, computers employ processors to process information;such processors 3203 may be referred to as central processing units(CPU). One form of processor is referred to as a microprocessor. CPUsuse communicative circuits to pass binary encoded signals acting asinstructions to enable various operations. These instructions may beoperational and/or data instructions containing and/or referencing otherinstructions and data in various processor accessible and operable areasof memory 3229 (e.g., registers, cache memory, random access memory,etc.). Such communicative instructions may be stored and/or transmittedin batches (e.g., batches of instructions) as programs and/or datacomponents to facilitate desired operations. These stored instructioncodes, e.g., programs, may engage the CPU circuit components and othermotherboard and/or system components to perform desired operations. Onetype of program is a computer operating system, which, may be executedby CPU on a computer; the operating system enables and facilitates usersto access and operate computer information technology and resources.Some resources that may be employed in information technology systemsinclude: input and output mechanisms through which data may pass intoand out of a computer; memory storage into which data may be saved; andprocessors by which information may be processed. These informationtechnology systems may be used to collect data for later retrieval,analysis, and manipulation, which may be facilitated through a databaseprogram. These information technology systems provide interfaces thatallow users to access and operate various system components.

In one embodiment, the SFTSP controller 3201 may be connected to and/orcommunicate with entities such as, but not limited to: one or more usersfrom peripheral devices 3212 (e.g., user input devices 3211); anoptional cryptographic processor device 3228; and/or a communicationsnetwork 3213.

Networks comprise the interconnection and interoperation of clients,servers, and intermediary nodes in a graph topology. It should be notedthat the term “server” as used throughout this application refersgenerally to a computer, other device, program, or combination thereofthat processes and responds to the requests of remote users across acommunications network. Servers serve their information to requesting“clients.” The term “client” as used herein refers generally to acomputer, program, other device, user and/or combination thereof that iscapable of processing and making requests and obtaining and processingany responses from servers across a communications network. A computer,other device, program, or combination thereof that facilitates,processes information and requests, and/or furthers the passage ofinformation from a source user to a destination user is referred to as a“node.” Networks are generally thought to facilitate the transfer ofinformation from source points to destinations. A node specificallytasked with furthering the passage of information from a source to adestination is called a “router.” There are many forms of networks suchas Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs),Wireless Networks (WLANs), etc. For example, the Internet is, generally,an interconnection of a multitude of networks whereby remote clients andservers may access and interoperate with one another.

The SFTSP controller 3201 may be based on computer systems that maycomprise, but are not limited to, components such as: a computersystemization 3202 connected to memory 3229.

Computer Systemization

A computer systemization 3202 may comprise a clock 3230, centralprocessing unit (“CPU(s)” and/or “processor(s)” (these terms are usedinterchangeable throughout the disclosure unless noted to the contrary))3203, a memory 3229 (e.g., a read only memory (ROM) 3206, a randomaccess memory (RAM) 3205, etc.), and/or an interface bus 3207, and mostfrequently, although not necessarily, are all interconnected and/orcommunicating through a system bus 3204 on one or more (mother)board(s)3202 having conductive and/or otherwise transportive circuit pathwaysthrough which instructions (e.g., binary encoded signals) may travel toeffectuate communications, operations, storage, etc. The computersystemization may be connected to a power source 3286; e.g., optionallythe power source may be internal. Optionally, a cryptographic processor3226 may be connected to the system bus. In another embodiment, thecryptographic processor, transceivers (e.g., ICs) 3274, and/or sensorarray (e.g., accelerometer, altimeter, ambient light, barometer, globalpositioning system (GPS) (thereby allowing SFTSP controller to determineits location), gyroscope, magnetometer, pedometer, proximity,ultra-violet sensor, etc.) 3273 may be connected as either internaland/or external peripheral devices 3212 via the interface bus I/O 3208(not pictured) and/or directly via the interface bus 3207. In turn, thetransceivers may be connected to antenna(s) 3275, thereby effectuatingwireless transmission and reception of various communication and/orsensor protocols; for example the antenna(s) may connect to varioustransceiver chip sets (depending on deployment needs), including:Broadcom BCM4329FKUBG transceiver chip (e.g., providing 802.11n,Bluetooth 2.1+EDR, FM, etc.); a Broadcom BCM4752 GPS receiver withaccelerometer, altimeter, GPS, gyroscope, magnetometer; a BroadcomBCM4335 transceiver chip (e.g., providing 2G, 3G, and 4G long-termevolution (LTE) cellular communications; 802.11ac, Bluetooth 4.0 lowenergy (LE) (e.g., beacon features)); a Broadcom BCM43341 transceiverchip (e.g., providing 2G, 3G and 4G LTE cellular communications; 802.11g/, Bluetooth 4.0, near field communication (NFC), FM radio); anInfineon Technologies X-Gold 618-PMB9800 transceiver chip (e.g.,providing 2G/3G HSDPA/HSUPA communications); a MediaTek MT6620transceiver chip (e.g., providing 802.11a/ac/b/g/n, Bluetooth 4.0 LE,FM, GPS; a Lapis Semiconductor ML8511 UV sensor; a maxim integratedMAX44000 ambient light and infrared proximity sensor; a TexasInstruments WiLink WL1283 transceiver chip (e.g., providing 802.11n,Bluetooth 3.0, FM, GPS); and/or the like. The system clock may have acrystal oscillator and generates a base signal through the computersystemization's circuit pathways. The clock may be coupled to the systembus and various clock multipliers that will increase or decrease thebase operating frequency for other components interconnected in thecomputer systemization. The clock and various components in a computersystemization drive signals embodying information throughout the system.Such transmission and reception of instructions embodying informationthroughout a computer systemization may be referred to ascommunications. These communicative instructions may further betransmitted, received, and the cause of return and/or replycommunications beyond the instant computer systemization to:communications networks, input devices, other computer systemizations,peripheral devices, and/or the like. It should be understood that inalternative embodiments, any of the above components may be connecteddirectly to one another, connected to the CPU, and/or organized innumerous variations employed as exemplified by various computer systems.

The CPU comprises at least one high-speed data processor adequate toexecute program components for executing user and/or system-generatedrequests. The CPU is often packaged in a number of formats varying fromlarge supercomputer(s) and mainframe(s) computers, down to minicomputers, servers, desktop computers, laptops, thin clients (e.g.,Chromebooks), netbooks, tablets (e.g., Android, iPads, and Windowstablets, etc.), mobile smartphones (e.g., Android, iPhones, Nokia, Palmand Windows phones, etc.), wearable device(s) (e.g., watches, glasses,goggles (e.g., Google Glass), etc.), and/or the like. Often, theprocessors themselves will incorporate various specialized processingunits, such as, but not limited to: integrated system (bus) controllers,memory management control units, floating point units, and evenspecialized processing sub-units like graphics processing units, digitalsignal processing units, and/or the like. Additionally, processors mayinclude internal fast access addressable memory, and be capable ofmapping and addressing memory 3229 beyond the processor itself; internalmemory may include, but is not limited to: fast registers, variouslevels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc. Theprocessor may access this memory through the use of a memory addressspace that is accessible via instruction address, which the processorcan construct and decode allowing it to access a circuit path to aspecific memory address space having a memory state. The CPU may be amicroprocessor such as: AMD's Athlon, Duron and/or Opteron; Apple's Aseries of processors (e.g., A5, A6, A7, A8, etc.); ARM's application,embedded and secure processors; IBM and/or Motorola's DragonBall andPowerPC; IBM's and Sony's Cell processor; Intel's 80X86 series (e.g.,80386, 80486), Pentium, Celeron, Core (2) Duo, i series (e.g., i3, i5,i7, etc.), Itanium, Xeon, and/or XScale; Motorola's 680X0 series (e.g.,68020, 68030, 68040, etc.); and/or the like processor(s). The CPUinteracts with memory through instruction passing through conductiveand/or transportive conduits (e.g., (printed) electronic and/or opticcircuits) to execute stored instructions (i.e., program code) accordingto various data processing techniques. Such instruction passingfacilitates communication within the SFTSP controller and beyond throughvarious interfaces. Should processing requirements dictate a greateramount speed and/or capacity, distributed processors (e.g., seeDistributed SFTSP below), mainframe, multi-core, parallel, and/orsuper-computer architectures may similarly be employed. Alternatively,should deployment requirements dictate greater portability, smallermobile devices (e.g., Personal Digital Assistants (PDAs)) may beemployed.

Depending on the particular implementation, features of the SFTSP may beachieved by implementing a microcontroller such as CAST's R8051XC2microcontroller; Intel's MCS 51 (i.e., 8051 microcontroller); and/or thelike. Also, to implement certain features of the SFTSP, some featureimplementations may rely on embedded components, such as:Application-Specific Integrated Circuit (“ASIC”), Digital SignalProcessing (“DSP”), Field Programmable Gate Array (“FPGA”), and/or thelike embedded technology. For example, any of the SFTSP componentcollection (distributed or otherwise) and/or features may be implementedvia the microprocessor and/or via embedded components; e.g., via ASIC,coprocessor, DSP, FPGA, and/or the like. Alternately, someimplementations of the SFTSP may be implemented with embedded componentsthat are configured and used to achieve a variety of features or signalprocessing.

Depending on the particular implementation, the embedded components mayinclude software solutions, hardware solutions, and/or some combinationof both hardware/software solutions. For example, SFTSP featuresdiscussed herein may be achieved through implementing FPGAs, which are asemiconductor devices containing programmable logic components called“logic blocks”, and programmable interconnects, such as the highperformance FPGA Virtex series and/or the low cost Spartan seriesmanufactured by Xilinx. Logic blocks and interconnects can be programmedby the customer or designer, after the FPGA is manufactured, toimplement any of the SFTSP features. A hierarchy of programmableinterconnects allow logic blocks to be interconnected as needed by theSFTSP system designer/administrator, somewhat like a one-chipprogrammable breadboard. An FPGA's logic blocks can be programmed toperform the operation of basic logic gates such as AND, and XOR, or morecomplex combinational operators such as decoders or mathematicaloperations. In most FPGAs, the logic blocks also include memoryelements, which may be circuit flip-flops or more complete blocks ofmemory. In some circumstances, the SFTSP may be developed on FPGAs andthen migrated into a fixed version that more resembles ASICimplementations. Alternate or coordinating implementations may migrateSFTSP controller features to a final ASIC instead of or in addition toFPGAs. Depending on the implementation all of the aforementionedembedded components and microprocessors may be considered the “CPU”and/or “processor” for the SFTSP.

Power Source

The power source 3286 may be of any various form for powering smallelectronic circuit board devices such as the following powercells—alkaline, lithium hydride, lithium ion, lithium polymer, nickelcadmium, solar cells, and/or the like. Other types of AC or DC powersources may be used as well. In the case of solar cells, in oneembodiment, the case provides an aperture through which the solar cellmay capture photonic energy. The power cell 3286 is connected to atleast one of the interconnected subsequent components of the SFTSPthereby providing an electric current to all subsequent components. Inone example, the power source 3286 is connected to the system buscomponent 3204. In an alternative embodiment, an outside power source3286 is provided through a connection across the I/O 3208 interface. Forexample, a USB and/or IEEE 1394 connection carries both data and poweracross the connection and is therefore a suitable source of power.

Interface Adapters

Interface bus(ses) 3207 may accept, connect, and/or communicate to anumber of interface adapters, variously although not necessarily in theform of adapter cards, such as but not limited to: input outputinterfaces (I/O) 3208, storage interfaces 3209, network interfaces 3210,and/or the like. Optionally, cryptographic processor interfaces 3227similarly may be connected to the interface bus. The interface busprovides for the communications of interface adapters with one anotheras well as with other components of the computer systemization.Interface adapters are adapted for a compatible interface bus. Interfaceadapters variously connect to the interface bus via a slot architecture.Various slot architectures may be employed, such as, but not limited to:Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry StandardArchitecture ((E)ISA), Micro Channel Architecture (MCA), NuBus,Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express,Personal Computer Memory Card International Association (PCMCIA), and/orthe like.

Storage interfaces 3209 may accept, communicate, and/or connect to anumber of storage devices such as, but not limited to: storage devices3214, removable disc devices, and/or the like. Storage interfaces mayemploy connection protocols such as, but not limited to: (Ultra)(Serial) Advanced Technology Attachment (Packet Interface) ((Ultra)(Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE),Institute of Electrical and Electronics Engineers (IEEE) 1394, fiberchannel, Small Computer Systems Interface (SCSI), Universal Serial Bus(USB), and/or the like.

Network interfaces 3210 may accept, communicate, and/or connect to acommunications network 3213. Through a communications network 3213, theSFTSP controller is accessible through remote clients 3233 b (e.g.,computers with web browsers) by users 3233 a. Network interfaces mayemploy connection protocols such as, but not limited to: direct connect,Ethernet (thick, thin, twisted pair 10/100/1000/10000 Base T, and/or thelike), Token Ring, wireless connection such as IEEE 802.11a-x, and/orthe like. Should processing requirements dictate a greater amount speedand/or capacity, distributed network controllers (e.g., see DistributedSFTSP below), architectures may similarly be employed to pool, loadbalance, and/or otherwise decrease/increase the communicative bandwidthrequired by the SFTSP controller. A communications network may be anyone and/or the combination of the following: a direct interconnection;the Internet; Interplanetary Internet (e.g., Coherent File DistributionProtocol (CFDP), Space Communications Protocol Specifications (SCPS),etc.); a Local Area Network (LAN); a Metropolitan Area Network (MAN); anOperating Missions as Nodes on the Internet (OMNI); a secured customconnection; a Wide Area Network (WAN); a wireless network (e.g.,employing protocols such as, but not limited to a cellular, WiFi,Wireless Application Protocol (WAP), I-mode, and/or the like); and/orthe like. A network interface may be regarded as a specialized form ofan input output interface. Further, multiple network interfaces 3210 maybe used to engage with various communications network types 3213. Forexample, multiple network interfaces may be employed to allow for thecommunication over broadcast, multicast, and/or unicast networks.

Input Output interfaces (I/O) 3208 may accept, communicate, and/orconnect to user, peripheral devices 3212 (e.g., input devices 3211),cryptographic processor devices 3228, and/or the like. I/O may employconnection protocols such as, but not limited to: audio: analog,digital, monaural, RCA, stereo, and/or the like; data: Apple Desktop Bus(ADB), IEEE 1394a-b, serial, universal serial bus (USB); infrared;joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; touchinterfaces: capacitive, optical, resistive, etc. displays; videointerface: Apple Desktop Connector (ADC), BNC, coaxial, component,composite, digital, Digital Visual Interface (DVI), (mini) displayport,high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video,VGA, and/or the like; wireless transceivers: 802.11a/ac/b/g/n/x;Bluetooth; cellular (e.g., code division multiple access (CDMA), highspeed packet access (HSPA(+)), high-speed downlink packet access(HSDPA), global system for mobile communications (GSM), long termevolution (LTE), WiMax, etc.); and/or the like. One output device mayinclude a video display, which may comprise a Cathode Ray Tube (CRT) orLiquid Crystal Display (LCD) based monitor with an interface (e.g., DVIcircuitry and cable) that accepts signals from a video interface, may beused. The video interface composites information generated by a computersystemization and generates video signals based on the compositedinformation in a video memory frame. Another output device is atelevision set, which accepts signals from a video interface. The videointerface provides the composited video information through a videoconnection interface that accepts a video display interface (e.g., anRCA composite video connector accepting an RCA composite video cable; aDVI connector accepting a DVI display cable, etc.).

Peripheral devices 3212 may be connected and/or communicate to I/Oand/or other facilities of the like such as network interfaces, storageinterfaces, directly to the interface bus, system bus, the CPU, and/orthe like. Peripheral devices may be external, internal and/or part ofthe SFTSP controller. Peripheral devices may include: antenna, audiodevices (e.g., line-in, line-out, microphone input, speakers, etc.),cameras (e.g., gesture (e.g., Microsoft Kinect) detection, motiondetection, still, video, webcam, etc.), dongles (e.g., for copyprotection, ensuring secure transactions with a digital signature,and/or the like), external processors (for added capabilities; e.g.,crypto devices 528), force-feedback devices (e.g., vibrating motors),infrared (IR) transceiver, network interfaces, printers, scanners,sensors/sensor arrays and peripheral extensions (e.g., ambient light,GPS, gyroscopes, proximity, temperature, etc.), storage devices,transceivers (e.g., cellular, GPS, etc.), video devices (e.g., goggles,monitors, etc.), video sources, visors, and/or the like. Peripheraldevices often include types of input devices (e.g., cameras).

User input devices 3211 often are a type of peripheral device 512 (seeabove) and may include: card readers, dongles, finger print readers,gloves, graphics tablets, joysticks, keyboards, microphones, mouse(mice), remote controls, security/biometric devices (e.g., fingerprintreader, iris reader, retina reader, etc.), touch screens (e.g.,capacitive, resistive, etc.), trackballs, trackpads, styluses, and/orthe like.

It should be noted that although user input devices and peripheraldevices may be employed, the SFTSP controller may be embodied as anembedded, dedicated, and/or monitor-less (i.e., headless) device,wherein access would be provided over a network interface connection.

Cryptographic units such as, but not limited to, microcontrollers,processors 3226, interfaces 3227, and/or devices 3228 may be attached,and/or communicate with the SFTSP controller. A MC68HC16microcontroller, manufactured by Motorola Inc., may be used for and/orwithin cryptographic units. The MC68HC16 microcontroller utilizes a16-bit multiply-and-accumulate instruction in the 16 MHz configurationand requires less than one second to perform a 512-bit RSA private keyoperation. Cryptographic units support the authentication ofcommunications from interacting agents, as well as allowing foranonymous transactions. Cryptographic units may also be configured aspart of the CPU. Equivalent microcontrollers and/or processors may alsobe used. Other commercially available specialized cryptographicprocessors include: Broadcom's CryptoNetX and other Security Processors;nCipher's nShield; SafeNet's Luna PCI (e.g., 7100) series; SemaphoreCommunications' 40 MHz Roadrunner 184; Sun's Cryptographic Accelerators(e.g., Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); ViaNano Processor (e.g., L2100, L2200, U2400) line, which is capable ofperforming 500+MB/s of cryptographic instructions; VLSI Technology's 33MHz 6868; and/or the like.

Memory

Generally, any mechanization and/or embodiment allowing a processor toaffect the storage and/or retrieval of information is regarded as memory3229. However, memory is a fungible technology and resource, thus, anynumber of memory embodiments may be employed in lieu of or in concertwith one another. It is to be understood that the SFTSP controllerand/or a computer systemization may employ various forms of memory 3229.For example, a computer systemization may be configured wherein theoperation of on-chip CPU memory (e.g., registers), RAM, ROM, and anyother storage devices are provided by a paper punch tape or paper punchcard mechanism; however, such an embodiment would result in an extremelyslow rate of operation. In one configuration, memory 3229 will includeROM 3206, RAM 3205, and a storage device 3214. A storage device 3214 maybe any various computer system storage. Storage devices may include: anarray of devices (e.g., Redundant Array of Independent Disks (RAID)); adrum; a (fixed and/or removable) magnetic disk drive; a magneto-opticaldrive; an optical drive (i.e., Blueray, CD ROM/RAM/Recordable(R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.); RAM drives; solidstate memory devices (USB memory, solid state drives (SSD), etc.); otherprocessor-readable storage mediums; and/or other devices of the like.Thus, a computer systemization generally requires and makes use ofmemory.

Component Collection

The memory 3229 may contain a collection of program and/or databasecomponents and/or data such as, but not limited to: operating systemcomponent(s) 3215 (operating system); information server component(s)3216 (information server); user interface component(s) 3217 (userinterface); Web browser component(s) 3218 (Web browser); database(s)3219; mail server component(s) 3221; mail client component(s) 3222;cryptographic server component(s) 3220 (cryptographic server); the SFTSPcomponent(s) 3235; and/or the like (i.e., collectively a componentcollection). These components may be stored and accessed from thestorage devices and/or from storage devices accessible through aninterface bus. Although unconventional program components such as thosein the component collection, may be stored in a local storage device3214, they may also be loaded and/or stored in memory such as:peripheral devices, RAM, remote storage facilities through acommunications network, ROM, various forms of memory, and/or the like.

Operating System

The operating system component 3215 is an executable program componentfacilitating the operation of the SFTSP controller. The operating systemmay facilitate access of I/O, network interfaces, peripheral devices,storage devices, and/or the like. The operating system may be a highlyfault tolerant, scalable, and secure system such as: Apple's MacintoshOS X (Server); AT&T Plan 9; Be OS; Blackberry's QNX; Google's Chrome;Microsoft's Windows 7/8; Unix and Unix-like system distributions (suchas AT&T's UNIX; Berkley Software Distribution (BSD) variations such asFreeBSD, NetBSD, OpenBSD, and/or the like; Linux distributions such asRed Hat, Ubuntu, and/or the like); and/or the like operating systems.However, more limited and/or less secure operating systems also may beemployed such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, MicrosoftWindows 2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/Vista/XP (Server),Palm OS, and/or the like. Additionally, for robust mobile deploymentapplications, mobile operating systems may be used, such as: Apple'siOS; China Operating System COS; Google's Android; Microsoft WindowsRT/Phone; Palm's WebOS; Samsung/Intel's Tizen; and/or the like. Anoperating system may communicate to and/or with other components in acomponent collection, including itself, and/or the like. Mostfrequently, the operating system communicates with other programcomponents, user interfaces, and/or the like. For example, the operatingsystem may contain, communicate, generate, obtain, and/or provideprogram component, system, user, and/or data communications, requests,and/or responses. The operating system, once executed by the CPU, mayenable the interaction with communications networks, data, I/O,peripheral devices, program components, memory, user input devices,and/or the like. The operating system may provide communicationsprotocols that allow the SFTSP controller to communicate with otherentities through a communications network 3213. Various communicationprotocols may be used by the SFTSP controller as a subcarrier transportmechanism for interaction, such as, but not limited to: multicast,TCP/IP, UDP, unicast, and/or the like.

Information Server

An information server component 3216 is a stored program component thatis executed by a CPU. The information server may be an Internetinformation server such as, but not limited to Apache SoftwareFoundation's Apache, Microsoft's Internet Information Server, and/or thelike. The information server may allow for the execution of programcomponents through facilities such as Active Server Page (ASP), ActiveX,(ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface(CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH,Java, JavaScript, Practical Extraction Report Language (PERL), HypertextPre-Processor (PHP), pipes, Python, wireless application protocol (WAP),WebObjects, and/or the like. The information server may support securecommunications protocols such as, but not limited to, File TransferProtocol (FTP); HyperText Transfer Protocol (HTTP); Secure HypertextTransfer Protocol (HTTPS), Secure Socket Layer (SSL), messagingprotocols (e.g., America Online (AOL) Instant Messenger (AIM),Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), MicrosoftNetwork (MSN) Messenger Service, Presence and Instant Messaging Protocol(PRIM), Internet Engineering Task Force's (IETF's) Session InitiationProtocol (SIP), SIP for Instant Messaging and Presence LeveragingExtensions (SIMPLE), open XML-based Extensible Messaging and PresenceProtocol (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) InstantMessaging and Presence Service (IMPS)), Yahoo! Instant MessengerService, and/or the like. The information server provides results in theform of Web pages to Web browsers, and allows for the manipulatedgeneration of the Web pages through interaction with other programcomponents. After a Domain Name System (DNS) resolution portion of anHTTP request is resolved to a particular information server, theinformation server resolves requests for information at specifiedlocations on the SFTSP controller based on the remainder of the HTTPrequest. For example, a request such ashttp://123.124.125.126/myInformation.html might have the IP portion ofthe request “123.124.125.126” resolved by a DNS server to an informationserver at that IP address; that information server might in turn furtherparse the http request for the “/myInformation.html” portion of therequest and resolve it to a location in memory containing theinformation “myInformation.html.” Additionally, other informationserving protocols may be employed across various ports, e.g., FTPcommunications across port 21, and/or the like. An information servermay communicate to and/or with other components in a componentcollection, including itself, and/or facilities of the like. Mostfrequently, the information server communicates with the SFTSP database3219, operating systems, other program components, user interfaces, Webbrowsers, and/or the like.

Access to the SFTSP database may be achieved through a number ofdatabase bridge mechanisms such as through scripting languages asenumerated below (e.g., CGI) and through inter-application communicationchannels as enumerated below (e.g., CORBA, WebObjects, etc.). Any datarequests through a Web browser are parsed through the bridge mechanisminto appropriate grammars as required by the SFTSP. In one embodiment,the information server would provide a Web form accessible by a Webbrowser. Entries made into supplied fields in the Web form are tagged ashaving been entered into the particular fields, and parsed as such. Theentered terms are then passed along with the field tags, which act toinstruct the parser to generate queries directed to appropriate tablesand/or fields. In one embodiment, the parser may generate queries in SQLby instantiating a search string with the proper join/select commandsbased on the tagged text entries, wherein the resulting command isprovided over the bridge mechanism to the SFTSP as a query. Upongenerating query results from the query, the results are passed over thebridge mechanism, and may be parsed for formatting and generation of anew results Web page by the bridge mechanism. Such a new results Webpage is then provided to the information server, which may supply it tothe requesting Web browser.

Also, an information server may contain, communicate, generate, obtain,and/or provide program component, system, user, and/or datacommunications, requests, and/or responses.

User Interface

Computer interfaces in some respects are similar to automobile operationinterfaces. Automobile operation interface elements such as steeringwheels, gearshifts, and speedometers facilitate the access, operation,and display of automobile resources, and status. Computer interactioninterface elements such as check boxes, cursors, menus, scrollers, andwindows (collectively referred to as widgets) similarly facilitate theaccess, capabilities, operation, and display of data and computerhardware and operating system resources, and status. Operationinterfaces are called user interfaces. Graphical user interfaces (GUIs)such as the Apple's iOS, Macintosh Operating System's Aqua; IBM's OS/2;Google's Chrome (e.g., and other webbrowser/cloud based client OSs);Microsoft's Windows varied UIs2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/Vista/XP (Server) (i.e.,Aero, Surface, etc.); Unix's X-Windows (e.g., which may includeadditional Unix graphic interface libraries and layers such as K DesktopEnvironment (KDE), mythTV and GNU Network Object Model Environment(GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH,Java, JavaScript, etc. interface libraries such as, but not limited to,Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject,Yahoo! User Interface, any of which may be used and) provide a baselineand means of accessing and displaying information graphically to users.

A user interface component 3217 is a stored program component that isexecuted by a CPU. The user interface may be a graphic user interface asprovided by, with, and/or atop operating systems and/or operatingenvironments such as already discussed. The user interface may allow forthe display, execution, interaction, manipulation, and/or operation ofprogram components and/or system facilities through textual and/orgraphical facilities. The user interface provides a facility throughwhich users may affect, interact, and/or operate a computer system. Auser interface may communicate to and/or with other components in acomponent collection, including itself, and/or facilities of the like.Most frequently, the user interface communicates with operating systems,other program components, and/or the like. The user interface maycontain, communicate, generate, obtain, and/or provide programcomponent, system, user, and/or data communications, requests, and/orresponses.

Web Browser

A Web browser component 3218 is a stored program component that isexecuted by a CPU. The Web browser may be a hypertext viewingapplication such as Apple's (mobile) Safari, Google's Chrome, MicrosoftInternet Explorer, Mozilla's Firefox, Netscape Navigator, and/or thelike. Secure Web browsing may be supplied with 128 bit (or greater)encryption by way of HTTPS, SSL, and/or the like. Web browsers allowingfor the execution of program components through facilities such asActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-inAPIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or thelike. Web browsers and like information access tools may be integratedinto PDAs, cellular telephones, and/or other mobile devices. A Webbrowser may communicate to and/or with other components in a componentcollection, including itself, and/or facilities of the like. Mostfrequently, the Web browser communicates with information servers,operating systems, integrated program components (e.g., plug-ins),and/or the like; e.g., it may contain, communicate, generate, obtain,and/or provide program component, system, user, and/or datacommunications, requests, and/or responses. Also, in place of a Webbrowser and information server, a combined application may be developedto perform similar operations of both. The combined application wouldsimilarly affect the obtaining and the provision of information tousers, user agents, and/or the like from the SFTSP enabled nodes. Thecombined application may be nugatory on systems employing Web browsers.

Mail Server

A mail server component 3221 is a stored program component that isexecuted by a CPU 3203. The mail server may be an Internet mail serversuch as, but not limited to: dovecot, Courier IMAP, Cyrus IMAP, Maildir,Microsoft Exchange, sendmail, and/or the like. The mail server may allowfor the execution of program components through facilities such as ASP,ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts, Java,JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. Themail server may support communications protocols such as, but notlimited to: Internet message access protocol (IMAP), MessagingApplication Programming Interface (MAPI)/Microsoft Exchange, post officeprotocol (POPS), simple mail transfer protocol (SMTP), and/or the like.The mail server can route, forward, and process incoming and outgoingmail messages that have been sent, relayed and/or otherwise traversingthrough and/or to the SFTSP. Alternatively, the mail server componentmay be distributed out to mail service providing entities such asGoogle's cloud services (e.g., Gmail and notifications may alternativelybe provided via messenger services such as AOL's Instant Messenger,Apple's iMessage, Google Messenger, SnapChat, etc.).

Access to the SFTSP mail may be achieved through a number of APIsoffered by the individual Web server components and/or the operatingsystem.

Also, a mail server may contain, communicate, generate, obtain, and/orprovide program component, system, user, and/or data communications,requests, information, and/or responses.

Mail Client

A mail client component 3222 is a stored program component that isexecuted by a CPU 3203. The mail client may be a mail viewingapplication such as Apple Mail, Microsoft Entourage, Microsoft Outlook,Microsoft Outlook Express, Mozilla, Thunderbird, and/or the like. Mailclients may support a number of transfer protocols, such as: IMAP,Microsoft Exchange, POPS, SMTP, and/or the like. A mail client maycommunicate to and/or with other components in a component collection,including itself, and/or facilities of the like. Most frequently, themail client communicates with mail servers, operating systems, othermail clients, and/or the like; e.g., it may contain, communicate,generate, obtain, and/or provide program component, system, user, and/ordata communications, requests, information, and/or responses. Generally,the mail client provides a facility to compose and transmit electronicmail messages.

Cryptographic Server

A cryptographic server component 3220 is a stored program component thatis executed by a CPU 3203, cryptographic processor 3226, cryptographicprocessor interface 3227, cryptographic processor device 3228, and/orthe like. Cryptographic processor interfaces will allow for expeditionof encryption and/or decryption requests by the cryptographic component;however, the cryptographic component, alternatively, may run on a CPU.The cryptographic component allows for the encryption and/or decryptionof provided data. The cryptographic component allows for both symmetricand asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/ordecryption. The cryptographic component may employ cryptographictechniques such as, but not limited to: digital certificates (e.g.,X.509 authentication framework), digital signatures, dual signatures,enveloping, password access protection, public key management, and/orthe like. The cryptographic component will facilitate numerous(encryption and/or decryption) security protocols such as, but notlimited to: checksum, Data Encryption Standard (DES), Elliptical CurveEncryption (ECC), International Data Encryption Algorithm (IDEA),Message Digest 5 (MD5, which is a one way hash operation), passwords,Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption andauthentication system that uses an algorithm developed in 1977 by RonRivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA),Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS),Transport Layer Security (TLS), and/or the like. Employing suchencryption security protocols, the SFTSP may encrypt all incoming and/oroutgoing communications and may serve as node within a virtual privatenetwork (VPN) with a wider communications network. The cryptographiccomponent facilitates the process of “security authorization” wherebyaccess to a resource is inhibited by a security protocol wherein thecryptographic component effects authorized access to the securedresource. In addition, the cryptographic component may provide uniqueidentifiers of content, e.g., employing and MD5 hash to obtain a uniquesignature for an digital audio file. A cryptographic component maycommunicate to and/or with other components in a component collection,including itself, and/or facilities of the like. The cryptographiccomponent supports encryption schemes allowing for the securetransmission of information across a communications network to enablethe SFTSP component to engage in secure transactions if so desired. Thecryptographic component facilitates the secure accessing of resources onthe SFTSP and facilitates the access of secured resources on remotesystems; i.e., it may act as a client and/or server of securedresources. Most frequently, the cryptographic component communicateswith information servers, operating systems, other program components,and/or the like. The cryptographic component may contain, communicate,generate, obtain, and/or provide program component, system, user, and/ordata communications, requests, and/or responses.

The SFTSP Database

The SFTSP database component 3219 may be embodied in a database and itsstored data. The database is a stored program component, which isexecuted by the CPU; the stored program component portion configuringthe CPU to process the stored data. The database may be a faulttolerant, relational, scalable, secure database such as MySQL, Oracle,Sybase, etc. may be used. Additionally, optimized fast memory anddistributed databases such as IBM's Netezza, MongoDB's MongoDB,opensource Hadoop, opensource VoltDB, SAP's Hana, etc. Relationaldatabases are an extension of a flat file. Relational databases consistof a series of related tables. The tables are interconnected via a keyfield. Use of the key field allows the combination of the tables byindexing against the key field; i.e., the key fields act as dimensionalpivot points for combining information from various tables.Relationships generally identify links maintained between tables bymatching primary keys. Primary keys represent fields that uniquelyidentify the rows of a table in a relational database. Alternative keyfields may be used from any of the fields having unique value sets, andin some alternatives, even non-unique values in combinations with otherfields. More precisely, they uniquely identify rows of a table on the“one” side of a one-to-many relationship.

Alternatively, the SFTSP database may be implemented using various otherdata-structures, such as an array, hash, (linked) list, struct,structured text file (e.g., XML), table, and/or the like. Suchdata-structures may be stored in memory and/or in (structured) files. Inanother alternative, an object-oriented database may be used, such asFrontier, ObjectStore, Poet, Zope, and/or the like. Object databases caninclude a number of object collections that are grouped and/or linkedtogether by common attributes; they may be related to other objectcollections by some common attributes. Object-oriented databases performsimilarly to relational databases with the exception that objects arenot just pieces of data but may have other types of capabilitiesencapsulated within a given object. If the SFTSP database is implementedas a data-structure, the use of the SFTSP database 3219 may beintegrated into another component such as the SFTSP component 3235.Also, the database may be implemented as a mix of data structures,objects, and relational structures. Databases may be consolidated and/ordistributed in countless variations (e.g., see Distributed SFTSP below).Portions of databases, e.g., tables, may be exported and/or imported andthus decentralized and/or integrated.

In one embodiment, the database component 3219 includes several tables3219 a-j:

An accounts table 3219 a includes fields such as, but not limited to: anaccountID, accountOwnerID, accountContactID, assetIDs, deviceIDs,paymentIDs, transactionIDs, userIDs, accountType (e.g., agent, entity(e.g., corporate, non-profit, partnership, etc.), individual, etc.),accountCreationDate, accountUpdateDate, accountName, accountNumber,routingNumber, linkWalletsID, accountPrioritAccaountRatio,accountAddress, accountState, accountZIPcode, accountCountry,accountEmail, accountPhone, accountAuthKey, accountIPaddress,accountURLAccessCode, accountPortNo, accountAuthorizationCode,accountAccessPrivileges, accountPreferences, accountRestrictions, and/orthe like;

A users table 3219 b includes fields such as, but not limited to: auserID, userSSN, taxID, userContactID, accountID, assetIDs, deviceIDs,paymentIDs, transactionIDs, userType (e.g., agent, entity (e.g.,corporate, non-profit, partnership, etc.), individual, etc.),namePrefix, firstName, middleName, lastName, nameSuffix, DateOfBirth,userAge, userName, userEmail, userSocialAccountID, contactType,contactRelationship, userPhone, userAddress, userCity, userState,userZlPCode, userCountry, userAuthorizationCode, userAccessPrivilges,userPreferences, userRestrictions, and/or the like (the user table maysupport and/or track multiple entity accounts on a SFTSP);

An devices table 3219 c includes fields such as, but not limited to:deviceID, sensorIDs, accountID, assetIDs, paymentIDs, deviceType,deviceName, deviceManufacturer, deviceModel, deviceVersion,deviceSerialNo, deviceIPaddress, deviceMACaddress, device_ECID,deviceUUID, deviceLocation, deviceCertificate, deviceOS, appIDs,deviceResources, deviceSession, authKey, deviceSecureKey,walletAppInstalledFlag, deviceAccessPrivileges, devicePreferences,deviceRestrictions, hardware_config, software_config, storage_location,sensor_value, pin_reading, data_length, channel_requirement,sensor_name, sensor_model_no, sensor_manufacturer, sensor_type,sensor_serial_number, sensor_power_requirement,device_power_requirement, location, sensor_associated_tool,sensor_dimensions, device_dimensions, sensor_communications_type,device_communications_type, power_percentage, power_condition,temperature_setting, speed_adjust, hold_duration, part_actuation, and/orthe like. Device table may, in some embodiments, include fieldscorresponding to one or more Bluetooth profiles, such as those publishedat https://www.bluetooth.org/en-us/specification/adopted-specifications,and/or other device specifications, and/or the like;

An apps table 3219 d includes fields such as, but not limited to: appID,appName, appType, appDependencies, accountID, deviceIDs, transactionID,userID, appStoreAuthKey, appStoreAccountID, appStoreIPaddress,appStoreURLaccessCode, appStorePortNo, appAccessPrivileges,appPreferences, appRestrictions, portNum, access_API_call,linked_wallets_list, and/or the like;

An assets table 3219 e includes fields such as, but not limited to:assetID, accountID, userID, distributorAccountID, distributorPaymentID,distributorOnwerID, assetOwnerID, assetType, assetSourceDeviceID,assetSourceDeviceType, assetSourceDeviceName,assetSourceDistributionChannelID, assetSourceDistributionChannelType,assetSourceDistributionChannelName, assetTargetChannelID,assetTargetChannelType, assetTargetChannelName, assetName,assetSeriesName, assetSeriesSeason, assetSeriesEpisode, assetCode,assetQuantity, assetCost, assetPrice, assetValue, assetManufactuer,assetModelNo, assetSerialNo, assetLocation, assetAddress, assetState,assetZIPcode, assetState, assetCountry, assetEmail, assetIPaddress,assetURLaccessCode, assetOwnerAccountID, subscriptionIDs,assetAuthroizationCode, assetAccessPrivileges, assetPreferences,assetRestrictions, assetAPI, assetAPIconnectionAddress, and/or the like;

A payments table 3219 f includes fields such as, but not limited to:paymentID, accountID, userID, couponID, couponValue, couponConditions,couponExpiration, paymentType, paymentAccountNo, paymentAccountName,paymentAccountAuthorizationCodes, paymentExpirationDate, paymentCCV,paymentRoutingNo, paymentRoutingType, paymentAddress, paymentState,paymentZlPcode, paymentCountry, paymentEmail, paymentAuthKey,paymentlPaddress, paymentURLaccessCode, paymentPortNo,paymentAccessPrivileges, paymentPreferences, payementRestrictions,and/or the like;

An transactions table 3219 g includes fields such as, but not limitedto: transactionID, accountID, assetIDs, deviceIDs, paymentIDs,transactionIDs, userID, merchantID, transactionType, transactionDate,transactionTime, transactionAmount, transactionQuantity,transactionDetails, productsList, productType, productTitle,productsSummary, productParamsList, transactionNo,transactionAccessPrivileges, transactionPreferences,transactionRestrictions, merchantAuthKey, merchantAuthCode, and/or thelike;

An merchants table 3219 h includes fields such as, but not limited to:merchantID, merchantTaxID, merchanteName, merchantContactUserID,accountID, issuerID, acquirerID, merchantEmail, merchantAddress,merchantState, merchantZIPcode, merchantCountry, merchantAuthKey,merchantIPaddress, portNum, merchantURLaccessCode, merchantPortNo,merchantAccessPrivileges, merchantPreferences, merchantRestrictions,and/or the like;

An ads table 3219 i includes fields such as, but not limited to: adID,advertiserID, adMerchantID, adNetworkID, adName, adTags, advertiserName,adSponsor, adTime, adGeo, adAttributes, adFormat, adProduct, adText,adMedia, adMediaID, adChannelID, adTagTime, adAudioSignature, adHash,adTemplateID, adTemplateData, adSourceID, adSourceName,adSourceServerlP, adSourceURL, adSourceSecurityProtocol, adSourceFTP,adAuthKey, adAccessPrivileges, adPreferences, adRestrictions,adNetworkXchangeID, adNetworkXchangeName, adNetworkXchangeCost,adNetworkXchangeMetricType (e.g., CPA, CPC, CPM, CTR, etc.),adNetworkXchangeMetricValue, adNetworkXchangeServer,adNetworkXchangePortNumber, publisherID, publisherAddress, publisherURL,publisherTag, publisherIndustry, publisherName, publisherDescription,siteDomain, siteURL, siteContent, siteTag, siteContext, sitelmpression,siteVisits, siteHeadline, sitePage, siteAdPrice, sitePlacement,sitePosition, bidID, bidExchange, bidOS, bidTarget, bidTimestamp,bidPrice, bidlmpressionID, bidType, bidScore, adType (e.g., mobile,desktop, wearable, largescreen, interstitial, etc.), assetID,merchantID, deviceID, userID, accountID, impressionID, impressionOS,impressionTimeStamp, impressionGeo, impressionAction, impressionType,impressionPublisherID, impressionPublisherURL, and/or the like;

A HSM table 3219 j includes fields such as, but not limited to: HSM_ID,walletID, masterPrivateKey, masterPublicKey, privateKeyDecryptionKey,publicKeyEncryptionKey, isPortableHSM_Utilized, associatedHSM_ID,masterPrivateKeyShare, and/or the like.

In one embodiment, the SFTSP database may interact with other databasesystems. For example, employing a distributed database system, queriesand data access by search SFTSP component may treat the combination ofthe SFTSP database, an integrated data security layer database as asingle database entity (e.g., see Distributed SFTSP below).

In one embodiment, user programs may contain various user interfaceprimitives, which may serve to update the SFTSP. Also, various accountsmay require custom database tables depending upon the environments andthe types of clients the SFTSP may need to serve. It should be notedthat any unique fields may be designated as a key field throughout. Inan alternative embodiment, these tables have been decentralized intotheir own databases and their respective database controllers (i.e.,individual database controllers for each of the above tables). Employingvarious data processing techniques, one may further distribute thedatabases over several computer systemizations and/or storage devices.Similarly, configurations of the decentralized database controllers maybe varied by consolidating and/or distributing the various databasecomponents 3219 a-j. The SFTSP may be configured to keep track ofvarious settings, inputs, and parameters via database controllers.

The SFTSP database may communicate to and/or with other components in acomponent collection, including itself, and/or facilities of the like.Most frequently, the SFTSP database communicates with the SFTSPcomponent, other program components, and/or the like. The database maycontain, retain, and provide information regarding other nodes and data.

The SFTSPs

The SFTSP component 3235 is a stored program component that is executedby a CPU. In one embodiment, the SFTSP component incorporates any and/orall combinations of the aspects of the SFTSP that was discussed in theprevious figures. As such, the SFTSP affects accessing, obtaining andthe provision of information, services, transactions, and/or the likeacross various communications networks. The features and embodiments ofthe SFTSP discussed herein increase network efficiency by reducing datatransfer requirements the use of more efficient data structures andmechanisms for their transfer and storage. As a consequence, more datamay be transferred in less time, and latencies with regard totransactions, are also reduced. In many cases, such reduction instorage, transfer time, bandwidth requirements, latencies, etc., willreduce the capacity and structural infrastructure requirements tosupport the SFTSP's features and facilities, and in many cases reducethe costs, energy consumption/requirements, and extend the life ofSFTSP's underlying infrastructure; this has the added benefit of makingthe SFTSP more reliable. Similarly, many of the features and mechanismsare designed to be easier for users to use and access, therebybroadening the audience that may enjoy/employ and exploit the featuresets of the SFTSP; such ease of use also helps to increase thereliability of the SFTSP. In addition, the feature sets includeheightened security as noted via the Cryptographic components 3220,3226, 3228 and throughout, making access to the features and data morereliable and secure

The SFTSP transforms transaction signing request, key backup request,key recovery request inputs, via SFTSP components (e.g., SFTS, BUKB,SFKB, RUKR, SFKR, TSTS, NTSTS, HSFTS, FTSTS, CSFTS), into transactionsigning response, key backup response, key recovery response outputs.

The SFTSP component enabling access of information between nodes may bedeveloped by employing various development tools and languages such as,but not limited to: Apache components, Assembly, ActiveX, binaryexecutables, (ANSI) (Objective-) C (++), C# and/or .NET, databaseadapters, CGI scripts, Java, JavaScript, mapping tools, procedural andobject oriented development tools, PERL, PHP, Python, shell scripts, SQLcommands, web application server extensions, web developmentenvironments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX &FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools;Prototype; script.aculo.us; Simple Object Access Protocol (SOAP);SWFObject; Yahoo! User Interface; and/or the like), WebObjects, and/orthe like. In one embodiment, the SFTSP server employs a cryptographicserver to encrypt and decrypt communications. The SFTSP component maycommunicate to and/or with other components in a component collection,including itself, and/or facilities of the like. Most frequently, theSFTSP component communicates with the SFTSP database, operating systems,other program components, and/or the like. The SFTSP may contain,communicate, generate, obtain, and/or provide program component, system,user, and/or data communications, requests, and/or responses.

Distributed SFTSPs

The structure and/or operation of any of the SFTSP node controllercomponents may be combined, consolidated, and/or distributed in anynumber of ways to facilitate development and/or deployment. Similarly,the component collection may be combined in any number of ways tofacilitate deployment and/or development. To accomplish this, one mayintegrate the components into a common code base or in a facility thatcan dynamically load the components on demand in an integrated fashion.As such a combination of hardware may be distributed within a location,within a region and/or globally where logical access to a controller maybe abstracted as a singular node, yet where a multitude of private,semiprivate and publically accessible node controllers (e.g., viadispersed data centers) are coordinated to serve requests (e.g.,providing private cloud, semi-private cloud, and public cloud computingresources) and allowing for the serving of such requests in discreteregions (e.g., isolated, local, regional, national, global cloudaccess).

The component collection may be consolidated and/or distributed incountless variations through various data processing and/or developmenttechniques. Multiple instances of any one of the program components inthe program component collection may be instantiated on a single node,and/or across numerous nodes to improve performance throughload-balancing and/or data-processing techniques. Furthermore, singleinstances may also be distributed across multiple controllers and/orstorage devices; e.g., databases. All program component instances andcontrollers working in concert may do so through various data processingcommunication techniques.

The configuration of the SFTSP controller will depend on the context ofsystem deployment. Factors such as, but not limited to, the budget,capacity, location, and/or use of the underlying hardware resources mayaffect deployment requirements and configuration. Regardless of if theconfiguration results in more consolidated and/or integrated programcomponents, results in a more distributed series of program components,and/or results in some combination between a consolidated anddistributed configuration, data may be communicated, obtained, and/orprovided. Instances of components consolidated into a common code basefrom the program component collection may communicate, obtain, and/orprovide data. This may be accomplished through intra-application dataprocessing communication techniques such as, but not limited to: datareferencing (e.g., pointers), internal messaging, object instancevariable communication, shared memory space, variable passing, and/orthe like. For example, cloud services such as Amazon Data Services®,Microsoft Azure®, Hewlett Packard Helion®, IBM® Cloud services allow forSFTSP controller and/or SFTSP component collections to be hosted in fullor partially for varying degrees of scale.

If component collection components are discrete, separate, and/orexternal to one another, then communicating, obtaining, and/or providingdata with and/or to other component components may be accomplishedthrough inter-application data processing communication techniques suchas, but not limited to: Application Program Interfaces (API) informationpassage; (distributed) Component Object Model ((D)COM), (Distributed)Object Linking and Embedding ((D)OLE), and/or the like), Common ObjectRequest Broker Architecture (CORBA), Jini local and remote applicationprogram interfaces, JavaScript Object Notation (JSON), Remote MethodInvocation (RMI), SOAP, process pipes, shared files, and/or the like.Messages sent between discrete component components forinter-application communication or within memory spaces of a singularcomponent for intra-application communication may be facilitated throughthe creation and parsing of a grammar A grammar may be developed byusing development tools such as lex, yacc, XML, and/or the like, whichallow for grammar generation and parsing capabilities, which in turn mayform the basis of communication messages within and between components.

For example, a grammar may be arranged to recognize the tokens of anHTTP post command, e.g.:

-   -   w3c-post http:// . . . Value1

where Value1 is discerned as being a parameter because “http://” is partof the grammar syntax, and what follows is considered part of the postvalue. Similarly, with such a grammar, a variable “Value1” may beinserted into an “http://” post command and then sent. The grammarsyntax itself may be presented as structured data that is interpretedand/or otherwise used to generate the parsing mechanism (e.g., a syntaxdescription text file as processed by lex, yacc, etc.). Also, once theparsing mechanism is generated and/or instantiated, it itself mayprocess and/or parse structured data such as, but not limited to:character (e.g., tab) delineated text, HTML, structured text streams,XML, and/or the like structured data. In another embodiment,inter-application data processing protocols themselves may haveintegrated and/or readily available parsers (e.g., JSON, SOAP, and/orlike parsers) that may be employed to parse (e.g., communications) data.Further, the parsing grammar may be used beyond message parsing, but mayalso be used to parse: databases, data collections, data stores,structured data, and/or the like. Again, the desired configuration willdepend upon the context, environment, and requirements of systemdeployment.

For example, in some implementations, the SFTSP controller may beexecuting a PHP script implementing a Secure Sockets Layer (“SSL”)socket server via the information server, which listens to incomingcommunications on a server port to which a client may send data, e.g.,data encoded in JSON format. Upon identifying an incoming communication,the PHP script may read the incoming message from the client device,parse the received JSON-encoded text data to extract information fromthe JSON-encoded text data into PHP script variables, and store the data(e.g., client identifying information, etc.) and/or extractedinformation in a relational database accessible using the StructuredQuery Language (“SQL”). An exemplary listing, written substantially inthe form of PHP/SQL commands, to accept JSON-encoded input data from aclient device via a SSL connection, parse the data to extract variables,and store the data to a database, is provided below:

<?PHP header(′Content-Type: text/plain′); // set ip address and port tolisten to for incoming data $address = ‘192.168.0.100’; $port = 255; //create a server-side SSL socket, listen for/accept incomingcommunication $sock = socket_create(AF_INET, SOCK_STREAM, 0);socket_bind($sock, $address, $port) or die(‘Could not bind to address’);socket_listen($sock); $client = socket_accept($sock); // read input datafrom client device in 1024 byte blocks until end of message do { $input= “”; $input = socket_read($client, 1024); $data .= $input; }while($input != “”); // parse data to extract variables $obj =json_decode($data, true); // store input data in a databasemysql_connect(″201.408.185.132″,$DBserver,$password); // access databaseserver mysql_select(″CLIENT_DB.SQL″); // select database to appendmysql_query(“INSERT INTO UserTable (transmission) VALUES ($data)”); //add data to UserTable table in a CLIENT databasemysql_close(″CLIENT_DB.SQL″); // close connection to database ?>

Also, the following resources may be used to provide example embodimentsregarding SOAP parser implementation:

-   -   http://www.xay.com/perl/site/lib/SOAP/Parser.html    -   http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc/referenceguide295.htm        and other parser implementations:    -   http://publib.boulderibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc/referenceguide259.htm        all of which are hereby expressly incorporated by reference.

Additional embodiments include:

-   1. A transaction signing apparatus, comprising:-   a memory;-   a component collection in the memory, including:    -   a secure firmware transaction signing component implemented by a        first hardware security module (HSM);-   a processor disposed in communication with the memory, and    configured to issue a plurality of processing instructions from the    component collection stored in the memory,    -   wherein the processor issues instructions from the secure        firmware transaction signing component, stored in the memory,        to:        -   receive, via at least one processor, a transaction signing            request message for a transaction;        -   obtain, via at least one processor, an encrypted master            private key associated with the transaction from a second            HSM;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a private key decryption key            associated with the first HSM;        -   decrypt, via at least one processor, by the first HSM, the            encrypted master private key using the retrieved private key            decryption key;        -   determine, via at least one processor, a transaction hash            and a keychain path associated with the transaction signing            request message;        -   generate, via at least one processor, by the first HSM, a            signing private key for the determined keychain path using            the decrypted master private key;        -   sign, via at least one processor, by the first HSM, the            determined transaction hash using the generated signing            private key to generate a signature; and        -   return, via at least one processor, the generated signature.-   2. The apparatus of embodiment 1, wherein the first HSM is a PCIe    appliance installed in a transaction signing server.-   3. The apparatus of embodiment 1, wherein the second HSM is a USB    appliance communicatively coupled to the first HSM via USB.-   4. The apparatus of embodiment 1, wherein the second HSM includes a    pin entry device.-   5. The apparatus of embodiment 4, wherein the second HSM provides    the encrypted master private key to the first HSM upon obtaining    separate credentials from a predetermined number of people.-   6. The apparatus of embodiment 1, wherein the second HSM also    implements a secure firmware transaction signing component.-   7. The apparatus of embodiment 1, wherein the transaction signing    request is an API call to a method exposed by the secure firmware    transaction signing component.-   8. The apparatus of embodiment 1, wherein the encrypted master    private key is encrypted, by the second HSM, using a public key    encryption key of the first HSM stored in the second HSM's    tamper-proof storage.-   9. The apparatus of embodiment 1, wherein the signing private key is    generated using a Bip32-based deterministic key derivation    procedure.-   10. The apparatus of embodiment 1, further, comprising:    -   the processor issues instructions from the secure firmware        transaction signing component, stored in the memory, to:        -   wipe, via at least one processor, temporary private key data            from the memory after generating the signature.-   11. The apparatus of embodiment 10, wherein the temporary private    key data includes the encrypted master private key, the decrypted    master private key, and the generated signing private key.-   12. The apparatus of embodiment 1, wherein the transaction hash is    signed in accordance with the hashing algorithm utilized by the    Bitcoin protocol.-   13. The apparatus of embodiment 1, wherein the signature is returned    in Distinguished Encoding Rules format.-   14. A processor-readable transaction signing non-transient physical    medium storing processor-executable components, the components,    comprising:-   a component collection stored in the medium, including:    -   a secure firmware transaction signing component implemented by a        first hardware security module (HSM);    -   wherein the secure firmware transaction signing component,        stored in the medium, includes processor-issuable instructions        to:        -   receive, via at least one processor, a transaction signing            request message for a transaction;        -   obtain, via at least one processor, an encrypted master            private key associated with the transaction from a second            HSM;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a private key decryption key            associated with the first HSM;        -   decrypt, via at least one processor, by the first HSM, the            encrypted master private key using the retrieved private key            decryption key;        -   determine, via at least one processor, a transaction hash            and a keychain path associated with the transaction signing            request message;        -   generate, via at least one processor, by the first HSM, a            signing private key for the determined keychain path using            the decrypted master private key;        -   sign, via at least one processor, by the first HSM, the            determined transaction hash using the generated signing            private key to generate a signature; and        -   return, via at least one processor, the generated signature.-   15. The medium of embodiment 14, wherein the first HSM is a PCIe    appliance installed in a transaction signing server.-   16. The medium of embodiment 14, wherein the second HSM is a USB    appliance communicatively coupled to the first HSM via USB.-   17. The medium of embodiment 14, wherein the second HSM includes a    pin entry device.-   18. The medium of embodiment 17, wherein the second HSM provides the    encrypted master private key to the first HSM upon obtaining    separate credentials from a predetermined number of people.-   19. The medium of embodiment 14, wherein the second HSM also    implements a secure firmware transaction signing component.-   20. The medium of embodiment 14, wherein the transaction signing    request is an API call to a method exposed by the secure firmware    transaction signing component.-   21. The medium of embodiment 14, wherein the encrypted master    private key is encrypted, by the second HSM, using a public key    encryption key of the first HSM stored in the second HSM's    tamper-proof storage.-   22. The medium of embodiment 14, wherein the signing private key is    generated using a Bip32-based deterministic key derivation    procedure.-   23. The medium of embodiment 14, further, comprising:    -   the secure firmware transaction signing component, stored in the        medium, includes processor-issuable instructions to:        -   wipe, via at least one processor, temporary private key data            from the memory after generating the signature.-   24. The medium of embodiment 23, wherein the temporary private key    data includes the encrypted master private key, the decrypted master    private key, and the generated signing private key.-   25. The medium of embodiment 14, wherein the transaction hash is    signed in accordance with the hashing algorithm utilized by the    Bitcoin protocol.-   26. The medium of embodiment 14, wherein the signature is returned    in Distinguished Encoding Rules format.-   27. A processor-implemented transaction signing system, comprising:    -   secure firmware transaction signing component means implemented        by a first hardware security module (HSM), to:        -   receive, via at least one processor, a transaction signing            request message for a transaction;        -   obtain, via at least one processor, an encrypted master            private key associated with the transaction from a second            HSM;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a private key decryption key            associated with the first HSM;        -   decrypt, via at least one processor, by the first HSM, the            encrypted master private key using the retrieved private key            decryption key;        -   determine, via at least one processor, a transaction hash            and a keychain path associated with the transaction signing            request message;        -   generate, via at least one processor, by the first HSM, a            signing private key for the determined keychain path using            the decrypted master private key;        -   sign, via at least one processor, by the first HSM, the            determined transaction hash using the generated signing            private key to generate a signature; and        -   return, via at least one processor, the generated signature.-   28. The system of embodiment 27, wherein the first HSM is a PCIe    appliance installed in a transaction signing server.-   29. The system of embodiment 27, wherein the second HSM is a USB    appliance communicatively coupled to the first HSM via USB.-   30. The system of embodiment 27, wherein the second HSM includes a    pin entry device.-   31. The system of embodiment 30, wherein the second HSM provides the    encrypted master private key to the first HSM upon obtaining    separate credentials from a predetermined number of people.-   32. The system of embodiment 27, wherein the second HSM also    implements a secure firmware transaction signing component.-   33. The system of embodiment 27, wherein the transaction signing    request is an API call to a method exposed by the secure firmware    transaction signing component.-   34. The system of embodiment 27, wherein the encrypted master    private key is encrypted, by the second HSM, using a public key    encryption key of the first HSM stored in the second HSM's    tamper-proof storage.-   35. The system of embodiment 27, wherein the signing private key is    generated using a Bip32-based deterministic key derivation    procedure.-   36. The system of embodiment 27, further, comprising:    -   secure firmware transaction signing component means, to:        -   wipe, via at least one processor, temporary private key data            from the memory after generating the signature.-   37. The system of embodiment 36, wherein the temporary private key    data includes the encrypted master private key, the decrypted master    private key, and the generated signing private key.-   38. The system of embodiment 27, wherein the transaction hash is    signed in accordance with the hashing algorithm utilized by the    Bitcoin protocol.-   39. The system of embodiment 27, wherein the signature is returned    in Distinguished Encoding Rules format.-   40. A processor-implemented transaction signing method, comprising:    -   executing processor-implemented secure firmware transaction        signing component instructions implemented by a first hardware        security module (HSM), to:        -   receive, via at least one processor, a transaction signing            request message for a transaction;        -   obtain, via at least one processor, an encrypted master            private key associated with the transaction from a second            HSM;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a private key decryption key            associated with the first HSM;        -   decrypt, via at least one processor, by the first HSM, the            encrypted master private key using the retrieved private key            decryption key;        -   determine, via at least one processor, a transaction hash            and a keychain path associated with the transaction signing            request message;        -   generate, via at least one processor, by the first HSM, a            signing private key for the determined keychain path using            the decrypted master private key;        -   sign, via at least one processor, by the first HSM, the            determined transaction hash using the generated signing            private key to generate a signature; and return, via at            least one processor, the generated signature.-   41. The method of embodiment 40, wherein the first HSM is a PCIe    appliance installed in a transaction signing server.-   42. The method of embodiment 40, wherein the second HSM is a USB    appliance communicatively coupled to the first HSM via USB.-   43. The method of embodiment 40, wherein the second HSM includes a    pin entry device.-   44. The method of embodiment 43, wherein the second HSM provides the    encrypted master private key to the first HSM upon obtaining    separate credentials from a predetermined number of people.-   45. The method of embodiment 40, wherein the second HSM also    implements a secure firmware transaction signing component.-   46. The method of embodiment 40, wherein the transaction signing    request is an API call to a method exposed by the secure firmware    transaction signing component.-   47. The method of embodiment 40, wherein the encrypted master    private key is encrypted, by the second HSM, using a public key    encryption key of the first HSM stored in the second HSM's    tamper-proof storage.-   48. The method of embodiment 40, wherein the signing private key is    generated using a Bip32-based deterministic key derivation    procedure.-   49. The method of embodiment 40, further, comprising:    -   executing processor-implemented secure firmware transaction        signing component instructions to:        -   wipe, via at least one processor, temporary private key data            from the memory after generating the signature.-   50. The method of embodiment 49, wherein the temporary private key    data includes the encrypted master private key, the decrypted master    private key, and the generated signing private key.-   51. The method of embodiment 40, wherein the transaction hash is    signed in accordance with the hashing algorithm utilized by the    Bitcoin protocol.-   52. The method of embodiment 40, wherein the signature is returned    in Distinguished Encoding Rules format.-   101. A secure firmware key backup apparatus, comprising:-   a memory;-   a component collection in the memory, including:    -   a secure firmware key backup component implemented by a backup        hardware security module (HSM);-   a processor disposed in communication with the memory, and    configured to issue a plurality of processing instructions from the    component collection stored in the memory,    -   wherein the processor issues instructions from the secure        firmware key backup component, stored in the memory, to:        -   receive, via at least one processor, by the backup HSM, a            key backup request from a backup utility, wherein the key            backup request includes an encrypted master key associated            with a hosting HSM;        -   retrieve, via at least one processor, from the backup HSM's            tamper-proof storage, a private key decryption key            corresponding to a public key encryption key previously            provided by the backup HSM to the backup utility for the            hosting HSM, wherein the encrypted master key is encrypted            using the public key encryption key by the hosting HSM;        -   decrypt, via at least one processor, by the backup HSM, the            encrypted master key using the retrieved private key            decryption key;        -   determine, via at least one processor, by the backup HSM, a            specified number of master key shares to generate for the            decrypted master key;        -   generate, via at least one processor, by the backup HSM, the            specified number of master key shares using a secret sharing            method; and        -   provide, via at least one processor, by the backup HSM, the            generated master key shares to the backup utility.-   102. The apparatus of embodiment 101, wherein the backup HSM is a    PCIe appliance.-   103. The apparatus of embodiment 101, wherein the hosting HSM is a    USB appliance communicatively coupled to the backup HSM via USB.-   104. The apparatus of embodiment 101, wherein the key backup request    is an API call to a method exposed by the secure firmware key backup    component.-   105. The apparatus of embodiment 101, wherein the public key    encryption key and the corresponding private key decryption key are    predefined for the backup HSM.-   106. The apparatus of embodiment 101, wherein the public key    encryption key and the corresponding private key decryption key are    generated dynamically each time a key backup is executed.-   107. The apparatus of embodiment 101, wherein the secret sharing    method is Shamir's Secret Sharing.-   108. The apparatus of embodiment 101, further, comprising:    -   the processor issues instructions from the secure firmware key        backup component, stored in the memory, to:        -   determine, via at least one processor, by the backup HSM, a            specified number of master key shares sufficient to recover            the master key; and        -   wherein the master key shares are generated using the secret            sharing method based on the determined number of master key            shares sufficient to recover the master key.-   109. The apparatus of embodiment 101, further, comprising:    -   a backup utility key backup component in the component        collection, and    -   the processor issues instructions from the backup utility key        backup component, stored in the memory, to:        -   generate, via at least one processor, backup materials from            the generated master key shares.-   110. The apparatus of embodiment 109, wherein the backup materials    are any of: paper printouts, metal plates, plastic plates, USB keys,    hard drives, solid state drives, portable HSMs.-   111. The apparatus of embodiment 109, wherein the backup materials    are distributed for storage in geographically distributed backup    locations.-   112. The apparatus of embodiment 111, wherein each geographic backup    location stores a mixture of different types of backup materials.-   113. The apparatus of embodiment 101, further, comprising:    -   a secure firmware key recovery component in the component        collection, and    -   the processor issues instructions from the secure firmware key        recovery component, stored in the memory, to:        -   receive, via at least one processor, by a second backup HSM,            a key recovery request from a recovery utility, wherein the            key recovery request includes a set of master key shares            sufficient to recover the master key, wherein the key            recovery request includes a second public key encryption key            provided by a second hosting HSM, wherein the second public            key encryption key corresponds to a second private key            decryption key stored in tamper-proof storage of the second            hosting HSM;        -   recover, via at least one processor, by the second backup            HSM, the master key from the set of master key shares using            the secret sharing method;        -   encrypt, via at least one processor, by the second backup            HSM, the recovered master key using the second public key            encryption key; and        -   provide, via at least one processor, by the second backup            HSM, the encrypted recovered master key to the recovery            utility.-   114. The apparatus of embodiment 113, wherein the backup HSM and the    second backup HSM are the same HSM.-   115. The apparatus of embodiment 113, wherein the hosting HSM and    the second hosting HSM are the same HSM.-   116. A processor-readable secure firmware key backup non-transient    physical medium storing processor-executable components, the    components, comprising:-   a component collection stored in the medium, including:    -   a secure firmware key backup component implemented by a backup        hardware security module (HSM);    -   wherein the secure firmware key backup component, stored in the        medium, includes processor-issuable instructions to:        -   receive, via at least one processor, by the backup HSM, a            key backup request from a backup utility, wherein the key            backup request includes an encrypted master key associated            with a hosting HSM;        -   retrieve, via at least one processor, from the backup HSM's            tamper-proof storage, a private key decryption key            corresponding to a public key encryption key previously            provided by the backup HSM to the backup utility for the            hosting HSM, wherein the encrypted master key is encrypted            using the public key encryption key by the hosting HSM;        -   decrypt, via at least one processor, by the backup HSM, the            encrypted master key using the retrieved private key            decryption key;        -   determine, via at least one processor, by the backup HSM, a            specified number of master key shares to generate for the            decrypted master key;        -   generate, via at least one processor, by the backup HSM, the            specified number of master key shares using a secret sharing            method; and        -   provide, via at least one processor, by the backup HSM, the            generated master key shares to the backup utility.-   117. The medium of embodiment 116, wherein the backup HSM is a PCIe    appliance.-   118. The medium of embodiment 116, wherein the hosting HSM is a USB    appliance communicatively coupled to the backup HSM via USB.-   119. The medium of embodiment 116, wherein the key backup request is    an API call to a method exposed by the secure firmware key backup    component.-   120. The medium of embodiment 116, wherein the public key encryption    key and the corresponding private key decryption key are predefined    for the backup HSM.-   121. The medium of embodiment 116, wherein the public key encryption    key and the corresponding private key decryption key are generated    dynamically each time a key backup is executed.-   122. The medium of embodiment 116, wherein the secret sharing method    is Shamir's Secret Sharing.-   123. The medium of embodiment 116, further, comprising:    -   the secure firmware key backup component, stored in the medium,        includes processor-issuable instructions to:        -   determine, via at least one processor, by the backup HSM, a            specified number of master key shares sufficient to recover            the master key; and        -   wherein the master key shares are generated using the secret            sharing method based on the determined number of master key            shares sufficient to recover the master key.-   124. The medium of embodiment 116, further, comprising:    -   a backup utility key backup component in the component        collection, and    -   the backup utility key backup component, stored in the medium,        includes processor-issuable instructions to:        -   generate, via at least one processor, backup materials from            the generated master key shares.-   125. The medium of embodiment 124, wherein the backup materials are    any of: paper printouts, metal plates, plastic plates, USB keys,    hard drives, solid state drives, portable HSMs.-   126. The medium of embodiment 124, wherein the backup materials are    distributed for storage in geographically distributed backup    locations.-   127. The medium of embodiment 126, wherein each geographic backup    location stores a mixture of different types of backup materials.-   128. The medium of embodiment 116, further, comprising:    -   a secure firmware key recovery component in the component        collection, and    -   the secure firmware key recovery component, stored in the        medium, includes processor-issuable instructions to:        -   receive, via at least one processor, by a second backup HSM,            a key recovery request from a recovery utility, wherein the            key recovery request includes a set of master key shares            sufficient to recover the master key, wherein the key            recovery request includes a second public key encryption key            provided by a second hosting HSM, wherein the second public            key encryption key corresponds to a second private key            decryption key stored in tamper-proof storage of the second            hosting HSM;        -   recover, via at least one processor, by the second backup            HSM, the master key from the set of master key shares using            the secret sharing method;        -   encrypt, via at least one processor, by the second backup            HSM, the recovered master key using the second public key            encryption key; and        -   provide, via at least one processor, by the second backup            HSM, the encrypted recovered master key to the recovery            utility.-   129. The medium of embodiment 128, wherein the backup HSM and the    second backup HSM are the same HSM.-   130. The medium of embodiment 128, wherein the hosting HSM and the    second hosting HSM are the same HSM.-   131. A processor-implemented secure firmware key backup system,    comprising:    -   a secure firmware key backup component means implemented by a        backup hardware security module (HSM), to:        -   receive, via at least one processor, by the backup HSM, a            key backup request from a backup utility, wherein the key            backup request includes an encrypted master key associated            with a hosting HSM;        -   retrieve, via at least one processor, from the backup HSM's            tamper-proof storage, a private key decryption key            corresponding to a public key encryption key previously            provided by the backup HSM to the backup utility for the            hosting HSM, wherein the encrypted master key is encrypted            using the public key encryption key by the hosting HSM;        -   decrypt, via at least one processor, by the backup HSM, the            encrypted master key using the retrieved private key            decryption key;        -   determine, via at least one processor, by the backup HSM, a            specified number of master key shares to generate for the            decrypted master key;        -   generate, via at least one processor, by the backup HSM, the            specified number of master key shares using a secret sharing            method; and        -   provide, via at least one processor, by the backup HSM, the            generated master key shares to the backup utility.-   132. The system of embodiment 131, wherein the backup HSM is a PCIe    appliance.-   133. The system of embodiment 131, wherein the hosting HSM is a USB    appliance communicatively coupled to the backup HSM via USB.-   134. The system of embodiment 131, wherein the key backup request is    an API call to a method exposed by the secure firmware key backup    component.-   135. The system of embodiment 131, wherein the public key encryption    key and the corresponding private key decryption key are predefined    for the backup HSM.-   136. The system of embodiment 131, wherein the public key encryption    key and the corresponding private key decryption key are generated    dynamically each time a key backup is executed.-   137. The system of embodiment 131, wherein the secret sharing method    is Shamir's Secret Sharing.-   138. The system of embodiment 131, further, comprising:    -   the secure firmware key backup component means, to:        -   determine, via at least one processor, by the backup HSM, a            specified number of master key shares sufficient to recover            the master key; and        -   wherein the master key shares are generated using the secret            sharing method based on the determined number of master key            shares sufficient to recover the master key.-   139. The system of embodiment 131, further, comprising:    -   a backup utility key backup component means, to:        -   generate, via at least one processor, backup materials from            the generated master key shares.-   140. The system of embodiment 139, wherein the backup materials are    any of: paper printouts, metal plates, plastic plates, USB keys,    hard drives, solid state drives, portable HSMs.-   141. The system of embodiment 139, wherein the backup materials are    distributed for storage in geographically distributed backup    locations.-   142. The system of embodiment 141, wherein each geographic backup    location stores a mixture of different types of backup materials.-   143. The system of embodiment 131, further, comprising:    -   a secure firmware key recovery component means, to:        -   receive, via at least one processor, by a second backup HSM,            a key recovery request from a recovery utility, wherein the            key recovery request includes a set of master key shares            sufficient to recover the master key, wherein the key            recovery request includes a second public key encryption key            provided by a second hosting HSM, wherein the second public            key encryption key corresponds to a second private key            decryption key stored in tamper-proof storage of the second            hosting HSM;        -   recover, via at least one processor, by the second backup            HSM, the master key from the set of master key shares using            the secret sharing method;        -   encrypt, via at least one processor, by the second backup            HSM, the recovered master key using the second public key            encryption key; and        -   provide, via at least one processor, by the second backup            HSM, the encrypted recovered master key to the recovery            utility.-   144. The system of embodiment 143, wherein the backup HSM and the    second backup HSM are the same HSM.-   145. The system of embodiment 143, wherein the hosting HSM and the    second hosting HSM are the same HSM.-   146. A processor-implemented secure firmware key backup method,    comprising:    -   executing processor-implemented secure firmware key backup        component instructions to:        -   receive, via at least one processor, by the backup HSM, a            key backup request from a backup utility, wherein the key            backup request includes an encrypted master key associated            with a hosting HSM;        -   retrieve, via at least one processor, from the backup HSM's            tamper-proof storage, a private key decryption key            corresponding to a public key encryption key previously            provided by the backup HSM to the backup utility for the            hosting HSM, wherein the encrypted master key is encrypted            using the public key encryption key by the hosting HSM;        -   decrypt, via at least one processor, by the backup HSM, the            encrypted master key using the retrieved private key            decryption key;        -   determine, via at least one processor, by the backup HSM, a            specified number of master key shares to generate for the            decrypted master key;        -   generate, via at least one processor, by the backup HSM, the            specified number of master key shares using a secret sharing            method; and        -   provide, via at least one processor, by the backup HSM, the            generated master key shares to the backup utility.-   147. The method of embodiment 146, wherein the backup HSM is a PCIe    appliance.-   148. The method of embodiment 146, wherein the hosting HSM is a USB    appliance communicatively coupled to the backup HSM via USB.-   149. The method of embodiment 146, wherein the key backup request is    an API call to a method exposed by the secure firmware key backup    component.-   150. The method of embodiment 146, wherein the public key encryption    key and the corresponding private key decryption key are predefined    for the backup HSM.-   151. The method of embodiment 146, wherein the public key encryption    key and the corresponding private key decryption key are generated    dynamically each time a key backup is executed.-   152. The method of embodiment 146, wherein the secret sharing method    is Shamir's Secret Sharing.-   153. The method of embodiment 146, further, comprising:    -   executing processor-implemented secure firmware key backup        component instructions to:        -   determine, via at least one processor, by the backup HSM, a            specified number of master key shares sufficient to recover            the master key; and        -   wherein the master key shares are generated using the secret            sharing method based on the determined number of master key            shares sufficient to recover the master key.-   154. The method of embodiment 146, further, comprising:    -   executing processor-implemented backup utility key backup        component instructions to:        -   generate, via at least one processor, backup materials from            the generated master key shares.-   155. The method of embodiment 154, wherein the backup materials are    any of: paper printouts, metal plates, plastic plates, USB keys,    hard drives, solid state drives, portable HSMs.-   156. The method of embodiment 154, wherein the backup materials are    distributed for storage in geographically distributed backup    locations.-   157. The method of embodiment 156, wherein each geographic backup    location stores a mixture of different types of backup materials.-   158. The method of embodiment 146, further, comprising:    -   executing processor-implemented secure firmware key recovery        component instructions to:        -   receive, via at least one processor, by a second backup HSM,            a key recovery request from a recovery utility, wherein the            key recovery request includes a set of master key shares            sufficient to recover the master key, wherein the key            recovery request includes a second public key encryption key            provided by a second hosting HSM, wherein the second public            key encryption key corresponds to a second private key            decryption key stored in tamper-proof storage of the second            hosting HSM;        -   recover, via at least one processor, by the second backup            HSM, the master key from the set of master key shares using            the secret sharing method;        -   encrypt, via at least one processor, by the second backup            HSM, the recovered master key using the second public key            encryption key; and        -   provide, via at least one processor, by the second backup            HSM, the encrypted recovered master key to the recovery            utility.-   159. The method of embodiment 158, wherein the backup HSM and the    second backup HSM are the same HSM.-   160. The method of embodiment 158, wherein the hosting HSM and the    second hosting HSM are the same HSM.-   171. The apparatus of embodiment 113, wherein the second backup HSM    requires the set of master key shares to include a first specified    number of master key shares stored on any physical backup materials    and a second specified number of master key shares stored on any    digital backup materials.-   172. The apparatus of embodiment 113, wherein the second backup HSM    requires the set of master key shares to include a first specified    number of master key shares stored on specified physical backup    materials and a second specified number of master key shares stored    on specified digital backup materials.-   173. The medium of embodiment 128, wherein the second backup HSM    requires the set of master key shares to include a first specified    number of master key shares stored on any physical backup materials    and a second specified number of master key shares stored on any    digital backup materials.-   174. The medium of embodiment 128, wherein the second backup HSM    requires the set of master key shares to include a first specified    number of master key shares stored on specified physical backup    materials and a second specified number of master key shares stored    on specified digital backup materials.-   175. The system of embodiment 143, wherein the second backup HSM    requires the set of master key shares to include a first specified    number of master key shares stored on any physical backup materials    and a second specified number of master key shares stored on any    digital backup materials.-   176. The system of embodiment 143, wherein the second backup HSM    requires the set of master key shares to include a first specified    number of master key shares stored on specified physical backup    materials and a second specified number of master key shares stored    on specified digital backup materials.-   177. The method of embodiment 158, wherein the second backup HSM    requires the set of master key shares to include a first specified    number of master key shares stored on any physical backup materials    and a second specified number of master key shares stored on any    digital backup materials.-   178. The method of embodiment 158, wherein the second backup HSM    requires the set of master key shares to include a first specified    number of master key shares stored on specified physical backup    materials and a second specified number of master key shares stored    on specified digital backup materials.-   201. A transaction signing apparatus, comprising:-   a memory;-   a component collection in the memory, including:    -   a secure firmware transaction signing component implemented by a        first hardware security module (HSM);-   a processor disposed in communication with the memory, and    configured to issue a plurality of processing instructions from the    component collection stored in the memory,    -   wherein the processor issues instructions from the secure        firmware transaction signing component, stored in the memory,        to:        -   receive, via at least one processor, by the first HSM, a            transaction signing request message for a transaction from a            transaction signing server (TSS), wherein the transaction            signing request message includes an encrypted second master            key share associated with a second HSM;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a private key decryption key            corresponding to a public key encryption key previously            provided by the first HSM to the TSS for the second HSM,            wherein the encrypted second master key share is encrypted            using the public key encryption key by the second HSM;        -   decrypt, via at least one processor, by the first HSM, the            encrypted second master key share using the retrieved            private key decryption key;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a first master key share;        -   recover, via at least one processor, by the first HSM, a            master private key from the first master key share and the            decrypted second master key share using a secret sharing            method;        -   determine, via at least one processor, by the first HSM, a            transaction hash and a keychain path associated with the            transaction signing request message;        -   generate, via at least one processor, by the first HSM, a            signing private key for the determined keychain path using            the recovered master private key;        -   sign, via at least one processor, by the first HSM, the            determined transaction hash using the generated signing            private key to generate a signature; and        -   return, via at least one processor, the generated signature.-   202. The apparatus of embodiment 201, wherein the first HSM is a    PCIe appliance.-   203. The apparatus of embodiment 201, wherein the second HSM is a    USB appliance communicatively coupled to the TSS via USB.-   204. The apparatus of embodiment 201, wherein the second HSM    includes an authentication entry device.-   205. The apparatus of embodiment 204, wherein the second HSM    provides the encrypted second master key share to the TSS upon    obtaining separate credentials via the authentication entry device    from a predetermined number of people.-   206. The apparatus of embodiment 205, wherein the second HSM    enforces M-of-N security policy for exporting the encrypted second    master key share, wherein access to the second HSM is controlled by    M-of-N authentication policy.-   207. The apparatus of embodiment 201, wherein the private key    decryption key and the public key encryption key are predefined for    the first HSM.-   208. The apparatus of embodiment 201, wherein the private key    decryption key and the public key encryption key are generated    dynamically each time a transaction signing request message is    received.-   209. The apparatus of embodiment 201, wherein the transaction    signing request message is an API call to a method exposed by the    secure firmware transaction signing component.-   210. The apparatus of embodiment 201, wherein the secret sharing    method is Shamir's Secret Sharing.-   211. The apparatus of embodiment 201, wherein the signing private    key is generated using a Bip32-based deterministic key derivation    procedure.-   212. The apparatus of embodiment 201, further, comprising:    -   the processor issues instructions from the secure firmware        transaction signing component, stored in the memory, to:        -   wipe, via at least one processor, temporary private key data            from the memory after generating the signature.-   213. The apparatus of embodiment 212, wherein the temporary private    key data includes the private key decryption key, the public key    encryption key, the encrypted second master key share, the decrypted    second master key share, the recovered master private key, and the    generated signing private key.-   214. The apparatus of embodiment 201, wherein the transaction hash    is signed in accordance with the hashing algorithm utilized by the    Bitcoin protocol.-   215. The apparatus of embodiment 201, wherein the signature is    returned in Distinguished Encoding Rules format.-   216. A processor-readable transaction signing non-transient physical    medium storing processor-executable components, the components,    comprising:-   a component collection stored in the medium, including:    -   a secure firmware transaction signing component implemented by a        first hardware security module (HSM);    -   wherein the secure firmware transaction signing component,        stored in the medium, includes processor-issuable instructions        to:        -   receive, via at least one processor, by the first HSM, a            transaction signing request message for a transaction from a            transaction signing server (TSS), wherein the transaction            signing request message includes an encrypted second master            key share associated with a second HSM;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a private key decryption key            corresponding to a public key encryption key previously            provided by the first HSM to the TSS for the second HSM,            wherein the encrypted second master key share is encrypted            using the public key encryption key by the second HSM;        -   decrypt, via at least one processor, by the first HSM, the            encrypted second master key share using the retrieved            private key decryption key;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a first master key share;        -   recover, via at least one processor, by the first HSM, a            master private key from the first master key share and the            decrypted second master key share using a secret sharing            method;        -   determine, via at least one processor, by the first HSM, a            transaction hash and a keychain path associated with the            transaction signing request message;        -   generate, via at least one processor, by the first HSM, a            signing private key for the determined keychain path using            the recovered master private key;        -   sign, via at least one processor, by the first HSM, the            determined transaction hash using the generated signing            private key to generate a signature; and        -   return, via at least one processor, the generated signature.-   217. The medium of embodiment 216, wherein the first HSM is a PCIe    appliance.-   218. The medium of embodiment 216, wherein the second HSM is a USB    appliance communicatively coupled to the TSS via USB.-   219. The medium of embodiment 216, wherein the second HSM includes    an authentication entry device.-   220. The medium of embodiment 219, wherein the second HSM provides    the encrypted second master key share to the TSS upon obtaining    separate credentials via the authentication entry device from a    predetermined number of people.-   221. The medium of embodiment 220, wherein the second HSM enforces    M-of-N security policy for exporting the encrypted second master key    share, wherein access to the second HSM is controlled by M-of-N    authentication policy.-   222. The medium of embodiment 216, wherein the private key    decryption key and the public key encryption key are predefined for    the first HSM.-   223. The medium of embodiment 216, wherein the private key    decryption key and the public key encryption key are generated    dynamically each time a transaction signing request message is    received.-   224. The medium of embodiment 216, wherein the transaction signing    request message is an API call to a method exposed by the secure    firmware transaction signing component.-   225. The medium of embodiment 216, wherein the secret sharing method    is Shamir's Secret Sharing.-   226. The medium of embodiment 216, wherein the signing private key    is generated using a Bip32-based deterministic key derivation    procedure.-   227. The medium of embodiment 216, further, comprising:    -   the secure firmware transaction signing component, stored in the        medium, includes processor-issuable instructions to:        -   wipe, via at least one processor, temporary private key data            from the memory after generating the signature.-   228. The medium of embodiment 227, wherein the temporary private key    data includes the private key decryption key, the public key    encryption key, the encrypted second master key share, the decrypted    second master key share, the recovered master private key, and the    generated signing private key.-   229. The medium of embodiment 216, wherein the transaction hash is    signed in accordance with the hashing algorithm utilized by the    Bitcoin protocol.-   230. The medium of embodiment 216, wherein the signature is returned    in Distinguished Encoding Rules format.-   231. A processor-implemented transaction signing system, comprising:    -   secure firmware transaction signing component means implemented        by a first hardware security module (HSM), to:        -   receive, via at least one processor, by the first HSM, a            transaction signing request message for a transaction from a            transaction signing server (TSS), wherein the transaction            signing request message includes an encrypted second master            key share associated with a second HSM;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a private key decryption key            corresponding to a public key encryption key previously            provided by the first HSM to the TSS for the second HSM,            wherein the encrypted second master key share is encrypted            using the public key encryption key by the second HSM;        -   decrypt, via at least one processor, by the first HSM, the            encrypted second master key share using the retrieved            private key decryption key;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a first master key share;        -   recover, via at least one processor, by the first HSM, a            master private key from the first master key share and the            decrypted second master key share using a secret sharing            method;        -   determine, via at least one processor, by the first HSM, a            transaction hash and a keychain path associated with the            transaction signing request message;        -   generate, via at least one processor, by the first HSM, a            signing private key for the determined keychain path using            the recovered master private key;        -   sign, via at least one processor, by the first HSM, the            determined transaction hash using the generated signing            private key to generate a signature; and        -   return, via at least one processor, the generated signature.-   232. The system of embodiment 231, wherein the first HSM is a PCIe    appliance.-   233. The system of embodiment 231, wherein the second HSM is a USB    appliance communicatively coupled to the TSS via USB.-   234. The system of embodiment 231, wherein the second HSM includes    an authentication entry device.-   235. The system of embodiment 234, wherein the second HSM provides    the encrypted second master key share to the TSS upon obtaining    separate credentials via the authentication entry device from a    predetermined number of people.-   236. The system of embodiment 235, wherein the second HSM enforces    M-of-N security policy for exporting the encrypted second master key    share, wherein access to the second HSM is controlled by M-of-N    authentication policy.-   237. The system of embodiment 231, wherein the private key    decryption key and the public key encryption key are predefined for    the first HSM.-   238. The system of embodiment 231, wherein the private key    decryption key and the public key encryption key are generated    dynamically each time a transaction signing request message is    received.-   239. The system of embodiment 231, wherein the transaction signing    request message is an API call to a method exposed by the secure    firmware transaction signing component.-   240. The system of embodiment 231, wherein the secret sharing method    is Shamir's Secret Sharing.-   241. The system of embodiment 231, wherein the signing private key    is generated using a Bip32-based deterministic key derivation    procedure.-   242. The system of embodiment 231, further, comprising:    -   secure firmware transaction signing component means, to:        -   wipe, via at least one processor, temporary private key data            from the memory after generating the signature.-   243. The system of embodiment 242, wherein the temporary private key    data includes the private key decryption key, the public key    encryption key, the encrypted second master key share, the decrypted    second master key share, the recovered master private key, and the    generated signing private key.-   244. The system of embodiment 231, wherein the transaction hash is    signed in accordance with the hashing algorithm utilized by the    Bitcoin protocol.-   245. The system of embodiment 231, wherein the signature is returned    in Distinguished Encoding Rules format.-   246. A processor-implemented transaction signing method, comprising:    -   executing processor-implemented secure firmware transaction        signing component instructions implemented by a first hardware        security module (HSM), to:        -   receive, via at least one processor, by the first HSM, a            transaction signing request message for a transaction from a            transaction signing server (TSS), wherein the transaction            signing request message includes an encrypted second master            key share associated with a second HSM;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a private key decryption key            corresponding to a public key encryption key previously            provided by the first HSM to the TSS for the second HSM,            wherein the encrypted second master key share is encrypted            using the public key encryption key by the second HSM;        -   decrypt, via at least one processor, by the first HSM, the            encrypted second master key share using the retrieved            private key decryption key;        -   retrieve, via at least one processor, from the first HSM's            tamper-proof storage, a first master key share;        -   recover, via at least one processor, by the first HSM, a            master private key from the first master key share and the            decrypted second master key share using a secret sharing            method;        -   determine, via at least one processor, by the first HSM, a            transaction hash and a keychain path associated with the            transaction signing request message;        -   generate, via at least one processor, by the first HSM, a            signing private key for the determined keychain path using            the recovered master private key;        -   sign, via at least one processor, by the first HSM, the            determined transaction hash using the generated signing            private key to generate a signature; and        -   return, via at least one processor, the generated signature.-   247. The method of embodiment 246, wherein the first HSM is a PCIe    appliance.-   248. The method of embodiment 246, wherein the second HSM is a USB    appliance communicatively coupled to the TSS via USB.-   249. The method of embodiment 246, wherein the second HSM includes    an authentication entry device.-   250. The method of embodiment 249, wherein the second HSM provides    the encrypted second master key share to the TSS upon obtaining    separate credentials via the authentication entry device from a    predetermined number of people.-   251. The method of embodiment 250, wherein the second HSM enforces    M-of-N security policy for exporting the encrypted second master key    share, wherein access to the second HSM is controlled by M-of-N    authentication policy.-   252. The method of embodiment 246, wherein the private key    decryption key and the public key encryption key are predefined for    the first HSM.-   253. The method of embodiment 246, wherein the private key    decryption key and the public key encryption key are generated    dynamically each time a transaction signing request message is    received.-   254. The method of embodiment 246, wherein the transaction signing    request message is an API call to a method exposed by the secure    firmware transaction signing component.-   255. The method of embodiment 246, wherein the secret sharing method    is Shamir's Secret Sharing.-   256. The method of embodiment 246, wherein the signing private key    is generated using a Bip32-based deterministic key derivation    procedure.-   257. The method of embodiment 246, further, comprising:    -   executing processor-implemented secure firmware transaction        signing component instructions to:        -   wipe, via at least one processor, temporary private key data            from the memory after generating the signature.-   258. The method of embodiment 257, wherein the temporary private key    data includes the private key decryption key, the public key    encryption key, the encrypted second master key share, the decrypted    second master key share, the recovered master private key, and the    generated signing private key.-   259. The method of embodiment 246, wherein the transaction hash is    signed in accordance with the hashing algorithm utilized by the    Bitcoin protocol.-   260. The method of embodiment 246, wherein the signature is returned    in Distinguished Encoding Rules format.-   301. A transaction signing apparatus, comprising:-   a memory;-   a component collection in the memory, including:    -   a hot secure firmware transaction signing component implemented        by a hot hardware security module (HSM), and    -   a cold secure firmware transaction signing component implemented        by a first cold HSM;-   a processor disposed in communication with the memory, and    configured to issue a plurality of processing instructions from the    component collection stored in the memory,    -   wherein the processor issues instructions from the hot secure        firmware transaction signing component, stored in the memory,        to:        -   receive, via at least one processor, by the hot HSM, an            online transaction signing request message for a transaction            from an online transaction signing server (TSS);        -   retrieve, via at least one processor, from the hot HSM's            tamper-proof storage, a third master key share;        -   determine, via at least one processor, by the hot HSM, a            public key encryption key of the first cold HSM;        -   encrypt, via at least one processor, by the hot HSM, the            third master key share using the public key encryption key            of the first cold HSM; and        -   return, via at least one processor, the encrypted third            master key share to the online TSS for transfer to an            offline TSS;    -   wherein the processor issues instructions from the cold secure        firmware transaction signing component, stored in the memory,        to:        -   receive, via at least one processor, by the first cold HSM,            an offline transaction signing request message for the            transaction from the offline TSS, wherein the offline            transaction signing request message includes: an encrypted            second master key share associated with a second cold HSM            and the encrypted third master key share associated with the            hot HSM;        -   retrieve, via at least one processor, from the first cold            HSM's tamper-proof storage, a private key decryption key of            the first cold HSM corresponding to the public key            encryption key of the first cold HSM previously provided to            the second cold HSM and to the hot HSM, wherein the            encrypted second master key share is encrypted using the            public key encryption key of the first cold HSM by the            second cold HSM;        -   decrypt, via at least one processor, by the first cold HSM,            the encrypted second master key share and the encrypted            third master key share using the retrieved private key            decryption key of the first cold HSM;        -   retrieve, via at least one processor, from the first cold            HSM's tamper-proof storage, a first master key share;        -   recover, via at least one processor, by the first cold HSM,            a master private key from the first master key share, the            decrypted second master key share and the decrypted third            master key share using a secret sharing method;        -   determine, via at least one processor, by the first cold            HSM, a keychain path associated with the offline transaction            signing request message;        -   generate, via at least one processor, by the first cold HSM,            a signing private key for the determined keychain path using            the recovered master private key;        -   sign, via at least one processor, by the first cold HSM, the            transaction using the generated signing private key to            generate a signature; and        -   return, via at least one processor, the generated signature.-   302. The apparatus of embodiment 301, further, comprising:    -   the processor issues instructions from the hot secure firmware        transaction signing component, stored in the memory, to:        -   determine, via at least one processor, by the hot HSM,            transaction data associated with the transaction;        -   retrieve, via at least one processor, from the hot HSM's            tamper-proof storage, a private signing key corresponding to            a public signing key of the hot HSM previously provided to            the first cold HSM;        -   sign, via at least one processor, by the hot HSM, the            transaction data; and        -   return, via at least one processor, the signed transaction            data to the online TSS for transfer to the offline TSS.-   303. The apparatus of embodiment 302, further, comprising:    -   the processor issues instructions from the cold secure firmware        transaction signing component, stored in the memory, to:        -   verify, via at least one processor, by the first cold HSM,            the signed transaction data using the public signing key of            the hot HSM.-   304. The apparatus of embodiment 301, wherein an external storage    device is utilized to transfer the encrypted third master key share    from the online TSS to the offline TSS.-   305. The apparatus of embodiment 301, wherein the hot HSM and the    first cold HSM are PCIe appliances.-   306. The apparatus of embodiment 301, wherein the second cold HSM is    a USB appliance communicatively coupled to the first cold HSM via    USB.-   307. The apparatus of embodiment 301, wherein the second cold HSM    includes an authentication entry device.-   308. The apparatus of embodiment 307, wherein the second cold HSM    provides the encrypted second master key share to the offline TSS    upon obtaining separate credentials via the authentication entry    device from a predetermined number of people.-   309. The apparatus of embodiment 308, wherein the second cold HSM    enforces M-of-N security policy for exporting the encrypted second    master key share, wherein access to the second cold HSM is    controlled by M-of-N authentication policy.-   310. The apparatus of embodiment 301, wherein the private key    decryption key of the first cold HSM and the public key encryption    key of the first cold HSM are predefined.-   311. The apparatus of embodiment 301, wherein the private key    decryption key of the first cold HSM and the public key encryption    key of the first cold HSM are generated dynamically for each    transaction.-   312. The apparatus of embodiment 301, wherein the secret sharing    method is Shamir's Secret Sharing.-   313. The apparatus of embodiment 301, further, comprising:    -   the processor issues instructions from the cold secure firmware        transaction signing component, stored in the memory, to:        -   wipe, via at least one processor, temporary key data from            the memory of the first cold HSM after generating the            signature.-   314. The apparatus of embodiment 313, wherein the temporary key data    includes the encrypted second master key share, the decrypted second    master key share, the encrypted third master key share, the    decrypted third master key share, the recovered master private key,    and the generated signing private key.-   315. The apparatus of embodiment 301, wherein the signature is    returned in Distinguished Encoding Rules format.-   316. A processor-readable transaction signing non-transient physical    medium storing processor-executable components, the components,    comprising:-   a component collection stored in the medium, including:    -   a hot secure firmware transaction signing component implemented        by a hot hardware security module (HSM), and    -   a cold secure firmware transaction signing component implemented        by a first cold HSM;    -   wherein the hot secure firmware transaction signing component,        stored in the medium, includes processor-issuable instructions        to:        -   receive, via at least one processor, by the hot HSM, an            online transaction signing request message for a transaction            from an online transaction signing server (TSS);        -   retrieve, via at least one processor, from the hot HSM's            tamper-proof storage, a third master key share;        -   determine, via at least one processor, by the hot HSM, a            public key encryption key of the first cold HSM;        -   encrypt, via at least one processor, by the hot HSM, the            third master key share using the public key encryption key            of the first cold HSM; and        -   return, via at least one processor, the encrypted third            master key share to the online TSS for transfer to an            offline TSS;    -   wherein the cold secure firmware transaction signing component,        stored in the medium, includes processor-issuable instructions        to:        -   receive, via at least one processor, by the first cold HSM,            an offline transaction signing request message for the            transaction from the offline TSS, wherein the offline            transaction signing request message includes: an encrypted            second master key share associated with a second cold HSM            and the encrypted third master key share associated with the            hot HSM;        -   retrieve, via at least one processor, from the first cold            HSM's tamper-proof storage, a private key decryption key of            the first cold HSM corresponding to the public key            encryption key of the first cold HSM previously provided to            the second cold HSM and to the hot HSM, wherein the            encrypted second master key share is encrypted using the            public key encryption key of the first cold HSM by the            second cold HSM;        -   decrypt, via at least one processor, by the first cold HSM,            the encrypted second master key share and the encrypted            third master key share using the retrieved private key            decryption key of the first cold HSM;        -   retrieve, via at least one processor, from the first cold            HSM's tamper-proof storage, a first master key share;        -   recover, via at least one processor, by the first cold HSM,            a master private key from the first master key share, the            decrypted second master key share and the decrypted third            master key share using a secret sharing method;        -   determine, via at least one processor, by the first cold            HSM, a keychain path associated with the offline transaction            signing request message;        -   generate, via at least one processor, by the first cold HSM,            a signing private key for the determined keychain path using            the recovered master private key;        -   sign, via at least one processor, by the first cold HSM, the            transaction using the generated signing private key to            generate a signature; and        -   return, via at least one processor, the generated signature.-   317. The medium of embodiment 316, further, comprising:    -   the hot secure firmware transaction signing component, stored in        the medium, includes processor-issuable instructions to:        -   determine, via at least one processor, by the hot HSM,            transaction data associated with the transaction;        -   retrieve, via at least one processor, from the hot HSM's            tamper-proof storage, a private signing key corresponding to            a public signing key of the hot HSM previously provided to            the first cold HSM;        -   sign, via at least one processor, by the hot HSM, the            transaction data; and        -   return, via at least one processor, the signed transaction            data to the online TSS for transfer to the offline TSS.-   318. The medium of embodiment 317, further, comprising:    -   the cold secure firmware transaction signing component, stored        in the medium, includes processor-issuable instructions to:        -   verify, via at least one processor, by the first cold HSM,            the signed transaction data using the public signing key of            the hot HSM.-   319. The medium of embodiment 316, wherein an external storage    device is utilized to transfer the encrypted third master key share    from the online TSS to the offline TSS.-   320. The medium of embodiment 316, wherein the hot HSM and the first    cold HSM are PCIe appliances.-   321. The medium of embodiment 316, wherein the second cold HSM is a    USB appliance communicatively coupled to the first cold HSM via USB.-   322. The medium of embodiment 316, wherein the second cold HSM    includes an authentication entry device.-   323. The medium of embodiment 322, wherein the second cold HSM    provides the encrypted second master key share to the offline TSS    upon obtaining separate credentials via the authentication entry    device from a predetermined number of people.-   324. The medium of embodiment 323, wherein the second cold HSM    enforces M-of-N security policy for exporting the encrypted second    master key share, wherein access to the second cold HSM is    controlled by M-of-N authentication policy.-   325. The medium of embodiment 316, wherein the private key    decryption key of the first cold HSM and the public key encryption    key of the first cold HSM are predefined.-   326. The medium of embodiment 316, wherein the private key    decryption key of the first cold HSM and the public key encryption    key of the first cold HSM are generated dynamically for each    transaction.-   327. The medium of embodiment 316, wherein the secret sharing method    is Shamir's Secret Sharing.-   328. The medium of embodiment 316, further, comprising:    -   the cold secure firmware transaction signing component, stored        in the medium, includes processor-issuable instructions to:        -   wipe, via at least one processor, temporary key data from            the memory of the first cold HSM after generating the            signature.-   329. The medium of embodiment 328, wherein the temporary key data    includes the encrypted second master key share, the decrypted second    master key share, the encrypted third master key share, the    decrypted third master key share, the recovered master private key,    and the generated signing private key.-   330. The medium of embodiment 316, wherein the signature is returned    in Distinguished Encoding Rules format.-   331. A processor-implemented transaction signing system, comprising:    -   a hot secure firmware transaction signing component means, to:        -   receive, via at least one processor, by the hot HSM, an            online transaction signing request message for a transaction            from an online transaction signing server (TSS);        -   retrieve, via at least one processor, from the hot HSM's            tamper-proof storage, a third master key share;        -   determine, via at least one processor, by the hot HSM, a            public key encryption key of the first cold HSM;        -   encrypt, via at least one processor, by the hot HSM, the            third master key share using the public key encryption key            of the first cold HSM; and        -   return, via at least one processor, the encrypted third            master key share to the online TSS for transfer to an            offline TSS;    -   a cold secure firmware transaction signing component means, to:        -   receive, via at least one processor, by the first cold HSM,            an offline transaction signing request message for the            transaction from the offline TSS, wherein the offline            transaction signing request message includes: an encrypted            second master key share associated with a second cold HSM            and the encrypted third master key share associated with the            hot HSM;        -   retrieve, via at least one processor, from the first cold            HSM's tamper-proof storage, a private key decryption key of            the first cold HSM corresponding to the public key            encryption key of the first cold HSM previously provided to            the second cold HSM and to the hot HSM, wherein the            encrypted second master key share is encrypted using the            public key encryption key of the first cold HSM by the            second cold HSM;        -   decrypt, via at least one processor, by the first cold HSM,            the encrypted second master key share and the encrypted            third master key share using the retrieved private key            decryption key of the first cold HSM;        -   retrieve, via at least one processor, from the first cold            HSM's tamper-proof storage, a first master key share;        -   recover, via at least one processor, by the first cold HSM,            a master private key from the first master key share, the            decrypted second master key share and the decrypted third            master key share using a secret sharing method;        -   determine, via at least one processor, by the first cold            HSM, a keychain path associated with the offline transaction            signing request message;        -   generate, via at least one processor, by the first cold HSM,            a signing private key for the determined keychain path using            the recovered master private key;        -   sign, via at least one processor, by the first cold HSM, the            transaction using the generated signing private key to            generate a signature; and        -   return, via at least one processor, the generated signature.-   332. The system of embodiment 331, further, comprising:    -   the hot secure firmware transaction signing component means, to:        -   determine, via at least one processor, by the hot HSM,            transaction data associated with the transaction;        -   retrieve, via at least one processor, from the hot HSM's            tamper-proof storage, a private signing key corresponding to            a public signing key of the hot HSM previously provided to            the first cold HSM;        -   sign, via at least one processor, by the hot HSM, the            transaction data; and        -   return, via at least one processor, the signed transaction            data to the online TSS for transfer to the offline TSS.-   333. The system of embodiment 332, further, comprising:    -   the cold secure firmware transaction signing component means,        to:        -   verify, via at least one processor, by the first cold HSM,            the signed transaction data using the public signing key of            the hot HSM.-   334. The system of embodiment 331, wherein an external storage    device is utilized to transfer the encrypted third master key share    from the online TSS to the offline TSS.-   335. The system of embodiment 331, wherein the hot HSM and the first    cold HSM are PCIe appliances.-   336. The system of embodiment 331, wherein the second cold HSM is a    USB appliance communicatively coupled to the first cold HSM via USB.-   337. The system of embodiment 331, wherein the second cold HSM    includes an authentication entry device.-   338. The system of embodiment 337, wherein the second cold HSM    provides the encrypted second master key share to the offline TSS    upon obtaining separate credentials via the authentication entry    device from a predetermined number of people.-   339. The system of embodiment 338, wherein the second cold HSM    enforces M-of-N security policy for exporting the encrypted second    master key share, wherein access to the second cold HSM is    controlled by M-of-N authentication policy.-   340. The system of embodiment 331, wherein the private key    decryption key of the first cold HSM and the public key encryption    key of the first cold HSM are predefined.-   341. The system of embodiment 331, wherein the private key    decryption key of the first cold HSM and the public key encryption    key of the first cold HSM are generated dynamically for each    transaction.-   342. The system of embodiment 331, wherein the secret sharing method    is Shamir's Secret Sharing.-   343. The system of embodiment 331, further, comprising:    -   the cold secure firmware transaction signing component means,        to:        -   wipe, via at least one processor, temporary key data from            the memory of the first cold HSM after generating the            signature.-   344. The system of embodiment 343, wherein the temporary key data    includes the encrypted second master key share, the decrypted second    master key share, the encrypted third master key share, the    decrypted third master key share, the recovered master private key,    and the generated signing private key.-   345. The system of embodiment 331, wherein the signature is returned    in Distinguished Encoding Rules format.-   346. A processor-implemented transaction signing method, comprising:    -   executing processor-implemented hot secure firmware transaction        signing component instructions to:        -   receive, via at least one processor, by the hot HSM, an            online transaction signing request message for a transaction            from an online transaction signing server (TSS);        -   retrieve, via at least one processor, from the hot HSM's            tamper-proof storage, a third master key share;        -   determine, via at least one processor, by the hot HSM, a            public key encryption key of the first cold HSM;        -   encrypt, via at least one processor, by the hot HSM, the            third master key share using the public key encryption key            of the first cold HSM; and        -   return, via at least one processor, the encrypted third            master key share to the online TSS for transfer to an            offline TSS;    -   executing processor-implemented cold secure firmware transaction        signing component instructions to:        -   receive, via at least one processor, by the first cold HSM,            an offline transaction signing request message for the            transaction from the offline TSS, wherein the offline            transaction signing request message includes: an encrypted            second master key share associated with a second cold HSM            and the encrypted third master key share associated with the            hot HSM;        -   retrieve, via at least one processor, from the first cold            HSM's tamper-proof storage, a private key decryption key of            the first cold HSM corresponding to the public key            encryption key of the first cold HSM previously provided to            the second cold HSM and to the hot HSM, wherein the            encrypted second master key share is encrypted using the            public key encryption key of the first cold HSM by the            second cold HSM;        -   decrypt, via at least one processor, by the first cold HSM,            the encrypted second master key share and the encrypted            third master key share using the retrieved private key            decryption key of the first cold HSM;        -   retrieve, via at least one processor, from the first cold            HSM's tamper-proof storage, a first master key share;        -   recover, via at least one processor, by the first cold HSM,            a master private key from the first master key share, the            decrypted second master key share and the decrypted third            master key share using a secret sharing method;        -   determine, via at least one processor, by the first cold            HSM, a keychain path associated with the offline transaction            signing request message;        -   generate, via at least one processor, by the first cold HSM,            a signing private key for the determined keychain path using            the recovered master private key;        -   sign, via at least one processor, by the first cold HSM, the            transaction using the generated signing private key to            generate a signature; and        -   return, via at least one processor, the generated signature.-   347. The method of embodiment 346, further, comprising:    -   executing processor-implemented hot secure firmware transaction        signing component instructions to:        -   determine, via at least one processor, by the hot HSM,            transaction data associated with the transaction;        -   retrieve, via at least one processor, from the hot HSM's            tamper-proof storage, a private signing key corresponding to            a public signing key of the hot HSM previously provided to            the first cold HSM;        -   sign, via at least one processor, by the hot HSM, the            transaction data; and        -   return, via at least one processor, the signed transaction            data to the online TSS for transfer to the offline TSS.-   348. The method of embodiment 347, further, comprising:    -   executing processor-implemented cold secure firmware transaction        signing component instructions to:        -   verify, via at least one processor, by the first cold HSM,            the signed transaction data using the public signing key of            the hot HSM.-   349. The method of embodiment 346, wherein an external storage    device is utilized to transfer the encrypted third master key share    from the online TSS to the offline TSS.-   350. The method of embodiment 346, wherein the hot HSM and the first    cold HSM are PCIe appliances.-   351. The method of embodiment 346, wherein the second cold HSM is a    USB appliance communicatively coupled to the first cold HSM via USB.-   352. The method of embodiment 346, wherein the second cold HSM    includes an authentication entry device.-   353. The method of embodiment 352, wherein the second cold HSM    provides the encrypted second master key share to the offline TSS    upon obtaining separate credentials via the authentication entry    device from a predetermined number of people.-   354. The method of embodiment 353, wherein the second cold HSM    enforces M-of-N security policy for exporting the encrypted second    master key share, wherein access to the second cold HSM is    controlled by M-of-N authentication policy.-   355. The method of embodiment 346, wherein the private key    decryption key of the first cold HSM and the public key encryption    key of the first cold HSM are predefined.-   356. The method of embodiment 346, wherein the private key    decryption key of the first cold HSM and the public key encryption    key of the first cold HSM are generated dynamically for each    transaction.-   357. The method of embodiment 346, wherein the secret sharing method    is Shamir's Secret Sharing.-   358. The method of embodiment 346, further, comprising:    -   executing processor-implemented cold secure firmware transaction        signing component instructions to:        -   wipe, via at least one processor, temporary key data from            the memory of the first cold HSM after generating the            signature.-   359. The method of embodiment 358, wherein the temporary key data    includes the encrypted second master key share, the decrypted second    master key share, the encrypted third master key share, the    decrypted third master key share, the recovered master private key,    and the generated signing private key.-   360. The method of embodiment 346, wherein the signature is returned    in Distinguished Encoding Rules format.

In order to address various issues and advance the art, the entirety ofthis application for Seed Splitting and Firmware Extension for SecureCryptocurrency Key Backup, Restore, and Transaction Signing PlatformApparatuses, Methods and Systems (including the Cover Page, Title,Headings, Field, Background, Summary, Brief Description of the Drawings,Detailed Description, Claims, Abstract, Figures, Appendices, andotherwise) shows, by way of illustration, various embodiments in whichthe claimed innovations may be practiced. The advantages and features ofthe application are of a representative sample of embodiments only, andare not exhaustive and/or exclusive. They are presented only to assistin understanding and teach the claimed principles. It should beunderstood that they are not representative of all claimed innovations.As such, certain aspects of the disclosure have not been discussedherein. That alternate embodiments may not have been presented for aspecific portion of the innovations or that further undescribedalternate embodiments may be available for a portion is not to beconsidered a disclaimer of those alternate embodiments. It will beappreciated that many of those undescribed embodiments incorporate thesame principles of the innovations and others are equivalent. Thus, itis to be understood that other embodiments may be utilized andfunctional, logical, operational, organizational, structural and/ortopological modifications may be made without departing from the scopeand/or spirit of the disclosure. As such, all examples and/orembodiments are deemed to be non-limiting throughout this disclosure.Further and to the extent any financial and/or investment examples areincluded, such examples are for illustrative purpose(s) only, and arenot, nor should they be interpreted, as investment advice. Also, noinference should be drawn regarding those embodiments discussed hereinrelative to those not discussed herein other than it is as such forpurposes of reducing space and repetition. For instance, it is to beunderstood that the logical and/or topological structure of anycombination of any program components (a component collection), othercomponents, data flow order, logic flow order, and/or any presentfeature sets as described in the figures and/or throughout are notlimited to a fixed operating order and/or arrangement, but rather, anydisclosed order is exemplary and all equivalents, regardless of order,are contemplated by the disclosure. Similarly, descriptions ofembodiments disclosed throughout this disclosure, any reference todirection or orientation is merely intended for convenience ofdescription and is not intended in any way to limit the scope ofdescribed embodiments. Relative terms such as “lower,” “upper,”“horizontal,” “vertical,” “above,” “below,” “up,” “down,” “top” and“bottom” as well as derivative thereof (e.g., “horizontally,”“downwardly,” “upwardly,” etc.) should not be construed to limitembodiments, and instead, again, are offered for convenience ofdescription of orientation. These relative descriptors are forconvenience of description only and do not require that any embodimentsbe constructed or operated in a particular orientation unless explicitlyindicated as such. Terms such as “attached,” “affixed,” “connected,”“coupled,” “interconnected,” and similar may refer to a relationshipwherein structures are secured or attached to one another eitherdirectly or indirectly through intervening structures, as well as bothmovable or rigid attachments or relationships, unless expresslydescribed otherwise. Furthermore, it is to be understood that suchfeatures are not limited to serial execution, but rather, any number ofthreads, processes, services, servers, and/or the like that may executeasynchronously, concurrently, in parallel, simultaneously,synchronously, and/or the like are contemplated by the disclosure. Assuch, some of these features may be mutually contradictory, in that theycannot be simultaneously present in a single embodiment. Similarly, somefeatures are applicable to one aspect of the innovations, andinapplicable to others. In addition, the disclosure includes otherinnovations not presently claimed. Applicant reserves all rights inthose presently unclaimed innovations including the right to claim suchinnovations, file additional applications, continuations, continuationsin part, divisions, and/or the like thereof. As such, it should beunderstood that advantages, embodiments, examples, functional, features,logical, operational, organizational, structural, topological, and/orother aspects of the disclosure are not to be considered limitations onthe disclosure as defined by the claims or limitations on equivalents tothe claims. It is to be understood that, depending on the particularneeds and/or characteristics of a SFTSP individual and/or enterpriseuser, database configuration and/or relational model, data type, datatransmission and/or network framework, syntax structure, and/or thelike, various embodiments of the SFTSP, may be implemented that enable agreat deal of flexibility and customization. For example, aspects of theSFTSP may be adapted for non-Bitcoin and/or non-Ethereum transactions.While various embodiments and discussions of the SFTSP have includedinformation technology, however, it is to be understood that theembodiments described herein may be readily configured and/or customizedfor a wide variety of other applications and/or implementations.

What is claimed is:
 1. A transaction signing apparatus, comprising: amemory; a component collection in the memory, including: a hot securefirmware transaction signing component implemented by a hot hardwaresecurity module (HSM), and a cold secure firmware transaction signingcomponent implemented by a first cold HSM; a processor disposed incommunication with the memory, and configured to issue a plurality ofprocessing instructions from the component collection stored in thememory, wherein the processor issues instructions from the hot securefirmware transaction signing component, stored in the memory, to:receive, via at least one processor, by the hot HSM, an onlinetransaction signing request message for a transaction from an onlinetransaction signing server (TSS); retrieve, via at least one processor,from the hot HSM's tamper-proof storage, a third master key share;determine, via at least one processor, by the hot HSM, a public keyencryption key of the first cold HSM; encrypt, via at least oneprocessor, by the hot HSM, the third master key share using the publickey encryption key of the first cold HSM; and return, via at least oneprocessor, the encrypted third master key share to the online TSS fortransfer to an offline TSS; wherein the processor issues instructionsfrom the cold secure firmware transaction signing component, stored inthe memory, to: receive, via at least one processor, by the first coldHSM, an offline transaction signing request message for the transactionfrom the offline TSS, wherein the offline transaction signing requestmessage includes: an encrypted second master key share associated with asecond cold HSM and the encrypted third master key share associated withthe hot HSM; retrieve, via at least one processor, from the first coldHSM's tamper-proof storage, a private key decryption key of the firstcold HSM corresponding to the public key encryption key of the firstcold HSM previously provided to the second cold HSM and to the hot HSM,wherein the encrypted second master key share is encrypted using thepublic key encryption key of the first cold HSM by the second cold HSM;decrypt, via at least one processor, by the first cold HSM, theencrypted second master key share and the encrypted third master keyshare using the retrieved private key decryption key of the first coldHSM; retrieve, via at least one processor, from the first cold HSM'stamper-proof storage, a first master key share; recover, via at leastone processor, by the first cold HSM, a master private key from thefirst master key share, the decrypted second master key share and thedecrypted third master key share using a secret sharing method;determine, via at least one processor, by the first cold HSM, a keychainpath associated with the offline transaction signing request message;generate, via at least one processor, by the first cold HSM, a signingprivate key for the determined keychain path using the recovered masterprivate key; sign, via at least one processor, by the first cold HSM,the transaction using the generated signing private key to generate asignature; and return, via at least one processor, the generatedsignature.
 2. The apparatus of claim 1, further, comprising: theprocessor issues instructions from the hot secure firmware transactionsigning component, stored in the memory, to: determine, via at least oneprocessor, by the hot HSM, transaction data associated with thetransaction; retrieve, via at least one processor, from the hot HSM'stamper-proof storage, a private signing key corresponding to a publicsigning key of the hot HSM previously provided to the first cold HSM;sign, via at least one processor, by the hot HSM, the transaction data;and return, via at least one processor, the signed transaction data tothe online TSS for transfer to the offline TSS.
 3. The apparatus ofclaim 2, further, comprising: the processor issues instructions from thecold secure firmware transaction signing component, stored in thememory, to: verify, via at least one processor, by the first cold HSM,the signed transaction data using the public signing key of the hot HSM.4. The apparatus of claim 1, wherein an external storage device isutilized to transfer the encrypted third master key share from theonline TSS to the offline TSS.
 5. The apparatus of claim 1, wherein thehot HSM and the first cold HSM are PCIe appliances.
 6. The apparatus ofclaim 1, wherein the second cold HSM is a USB appliance communicativelycoupled to the first cold HSM via USB.
 7. The apparatus of claim 1,wherein the second cold HSM includes an authentication entry device. 8.The apparatus of claim 7, wherein the second cold HSM provides theencrypted second master key share to the offline TSS upon obtainingseparate credentials via the authentication entry device from apredetermined number of people.
 9. The apparatus of claim 8, wherein thesecond cold HSM enforces M-of-N security policy for exporting theencrypted second master key share, wherein access to the second cold HSMis controlled by M-of-N authentication policy.
 10. The apparatus ofclaim 1, wherein the private key decryption key of the first cold HSMand the public key encryption key of the first cold HSM are predefined.11. The apparatus of claim 1, wherein the private key decryption key ofthe first cold HSM and the public key encryption key of the first coldHSM are generated dynamically for each transaction.
 12. The apparatus ofclaim 1, wherein the secret sharing method is Shamir's Secret Sharing.13. The apparatus of claim 1, further, comprising: the processor issuesinstructions from the cold secure firmware transaction signingcomponent, stored in the memory, to: wipe, via at least one processor,temporary key data from the memory of the first cold HSM aftergenerating the signature.
 14. The apparatus of claim 13, wherein thetemporary key data includes the encrypted second master key share, thedecrypted second master key share, the encrypted third master key share,the decrypted third master key share, the recovered master private key,and the generated signing private key.
 15. The apparatus of claim 1,wherein the signature is returned in Distinguished Encoding Rulesformat.
 16. A processor-readable transaction signing non-transientphysical medium storing processor-executable components, the components,comprising: a component collection stored in the medium, including: ahot secure firmware transaction signing component implemented by a hothardware security module (HSM), and a cold secure firmware transactionsigning component implemented by a first cold HSM; wherein the hotsecure firmware transaction signing component, stored in the medium,includes processor-issuable instructions to: receive, via at least oneprocessor, by the hot HSM, an online transaction signing request messagefor a transaction from an online transaction signing server (TSS);retrieve, via at least one processor, from the hot HSM's tamper-proofstorage, a third master key share; determine, via at least oneprocessor, by the hot HSM, a public key encryption key of the first coldHSM; encrypt, via at least one processor, by the hot HSM, the thirdmaster key share using the public key encryption key of the first coldHSM; and return, via at least one processor, the encrypted third masterkey share to the online TSS for transfer to an offline TSS; wherein thecold secure firmware transaction signing component, stored in themedium, includes processor-issuable instructions to: receive, via atleast one processor, by the first cold HSM, an offline transactionsigning request message for the transaction from the offline TSS,wherein the offline transaction signing request message includes: anencrypted second master key share associated with a second cold HSM andthe encrypted third master key share associated with the hot HSM;retrieve, via at least one processor, from the first cold HSM'stamper-proof storage, a private key decryption key of the first cold HSMcorresponding to the public key encryption key of the first cold HSMpreviously provided to the second cold HSM and to the hot HSM, whereinthe encrypted second master key share is encrypted using the public keyencryption key of the first cold HSM by the second cold HSM; decrypt,via at least one processor, by the first cold HSM, the encrypted secondmaster key share and the encrypted third master key share using theretrieved private key decryption key of the first cold HSM; retrieve,via at least one processor, from the first cold HSM's tamper-proofstorage, a first master key share; recover, via at least one processor,by the first cold HSM, a master private key from the first master keyshare, the decrypted second master key share and the decrypted thirdmaster key share using a secret sharing method; determine, via at leastone processor, by the first cold HSM, a keychain path associated withthe offline transaction signing request message; generate, via at leastone processor, by the first cold HSM, a signing private key for thedetermined keychain path using the recovered master private key; sign,via at least one processor, by the first cold HSM, the transaction usingthe generated signing private key to generate a signature; and return,via at least one processor, the generated signature.
 17. Aprocessor-implemented transaction signing system, comprising: a hotsecure firmware transaction signing component means, to: receive, via atleast one processor, by the hot HSM, an online transaction signingrequest message for a transaction from an online transaction signingserver (TSS); retrieve, via at least one processor, from the hot HSM'stamper-proof storage, a third master key share; determine, via at leastone processor, by the hot HSM, a public key encryption key of the firstcold HSM; encrypt, via at least one processor, by the hot HSM, the thirdmaster key share using the public key encryption key of the first coldHSM; and return, via at least one processor, the encrypted third masterkey share to the online TSS for transfer to an offline TSS; a coldsecure firmware transaction signing component means, to: receive, via atleast one processor, by the first cold HSM, an offline transactionsigning request message for the transaction from the offline TSS,wherein the offline transaction signing request message includes: anencrypted second master key share associated with a second cold HSM andthe encrypted third master key share associated with the hot HSM;retrieve, via at least one processor, from the first cold HSM'stamper-proof storage, a private key decryption key of the first cold HSMcorresponding to the public key encryption key of the first cold HSMpreviously provided to the second cold HSM and to the hot HSM, whereinthe encrypted second master key share is encrypted using the public keyencryption key of the first cold HSM by the second cold HSM; decrypt,via at least one processor, by the first cold HSM, the encrypted secondmaster key share and the encrypted third master key share using theretrieved private key decryption key of the first cold HSM; retrieve,via at least one processor, from the first cold HSM's tamper-proofstorage, a first master key share; recover, via at least one processor,by the first cold HSM, a master private key from the first master keyshare, the decrypted second master key share and the decrypted thirdmaster key share using a secret sharing method; determine, via at leastone processor, by the first cold HSM, a keychain path associated withthe offline transaction signing request message; generate, via at leastone processor, by the first cold HSM, a signing private key for thedetermined keychain path using the recovered master private key; sign,via at least one processor, by the first cold HSM, the transaction usingthe generated signing private key to generate a signature; and return,via at least one processor, the generated signature.
 18. Aprocessor-implemented transaction signing method, comprising: executingprocessor-implemented hot secure firmware transaction signing componentinstructions to: receive, via at least one processor, by the hot HSM, anonline transaction signing request message for a transaction from anonline transaction signing server (TSS); retrieve, via at least oneprocessor, from the hot HSM's tamper-proof storage, a third master keyshare; determine, via at least one processor, by the hot HSM, a publickey encryption key of the first cold HSM; encrypt, via at least oneprocessor, by the hot HSM, the third master key share using the publickey encryption key of the first cold HSM; and return, via at least oneprocessor, the encrypted third master key share to the online TSS fortransfer to an offline TSS; executing processor-implemented cold securefirmware transaction signing component instructions to: receive, via atleast one processor, by the first cold HSM, an offline transactionsigning request message for the transaction from the offline TSS,wherein the offline transaction signing request message includes: anencrypted second master key share associated with a second cold HSM andthe encrypted third master key share associated with the hot HSM;retrieve, via at least one processor, from the first cold HSM'stamper-proof storage, a private key decryption key of the first cold HSMcorresponding to the public key encryption key of the first cold HSMpreviously provided to the second cold HSM and to the hot HSM, whereinthe encrypted second master key share is encrypted using the public keyencryption key of the first cold HSM by the second cold HSM; decrypt,via at least one processor, by the first cold HSM, the encrypted secondmaster key share and the encrypted third master key share using theretrieved private key decryption key of the first cold HSM; retrieve,via at least one processor, from the first cold HSM's tamper-proofstorage, a first master key share; recover, via at least one processor,by the first cold HSM, a master private key from the first master keyshare, the decrypted second master key share and the decrypted thirdmaster key share using a secret sharing method; determine, via at leastone processor, by the first cold HSM, a keychain path associated withthe offline transaction signing request message; generate, via at leastone processor, by the first cold HSM, a signing private key for thedetermined keychain path using the recovered master private key; sign,via at least one processor, by the first cold HSM, the transaction usingthe generated signing private key to generate a signature; and return,via at least one processor, the generated signature.